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I.  Project  Background 


The  acquisition  of  a compiler  system  often  represents  the 
most  critical  aspect  in  the  development  of  a successful 
ioftware  system.  Heretofore,  virtually  no  guidelines 
were  provided  for  buyers  to  facilitate  the  soecification 
of  a new  compiler. 

Software  development  involves  many  considerations.  The 
selection  of  the  appropriate  language  tools  in  the  deve- 
lopment process  is  not  only  critical,  but  will  have  major 
effects  in  terms  of  cost,  development  time,  efficiency, 
portability,  and  ease  of  maintenance  and  modification. 

Minimizing  programming  errors  often  depends  a great  deal 
on  matching  the  complexity  of  the  application  with  an 
appropriate  programming  language.  Many  variables  should 
be  considered  when  deciding  on  the  features  of  a particular 
system. 

There  is  a myriad  of  facilities  and  features  that  a compiler 
system  might  possess  with  respect  to  a modern  computer 
system.  Also  there  is  no  doubt  that  the  specific  require- 
ments for  compiler  systems  in  different  installations  are 
widely  divergent  and  based  on  the  best  utilization  of 
available  resources  for  particular  applications. 
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II.  Objective 

The  purpose  of  this  research  and  development  project  was 
to  define  criteria  and  guidelines  which  could  be  used  in 
compiler  procurement  specification  and  acceptance  decision 
making  processes.  The  resultant  document,  "Compiler 
Fpecification/Acceptance  Handbook"  is  intended  to  be  used 
as  a guidebook  in  the  specification  of  a compiler  system 
and  in  the  analysis  of  its  acceptability. 


The  purpose  of  the  document  is  to  aid  the  compiler  pro- 
curement agency.  It  is  a guide  to  the  specification  of 
appropriate  compiler  design,  implementation,  testing  and 
acceptance.  Vo  attempt  was  made  to  design  or  suggest  a 
universal  set  of  tests  for  all  languages  and  compilers. 

In  many  cases,  automated  verification  systems  already 
exist  for  this  purpose  (JCVS  - JOVIAL  Compiler  Validation 
System) . It  does  suggest  topics  which  should  be  considered 
in  designing  tests  for  a specific  project  and  indicates 
usual  results  of  importance.  The  weighting  factors 
assigned  are  based  on  "sample"  systems  and  compiler 
requirements  and  are  by  no  means  fixed.  Each  agency  must 
assign  its  own  weights  and  relative  importance  to  each  item. 

The  sample  weights  are  hypothetical  guidelines  to  help  each 
procurement  agency  to  develop  its  own  historical  specification/ 
acceptance  criteria. 
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III.  The  Handbook 


The  compiler  tpecification  criteria  developed  provide  respon- 
sible individuals  with  a means  of  identifying  the  features 
and  facilities  a compiler  system  should  contain  to  best 
utilize  its  available  resources  within  the  necessary  budget 
and  time  constraints.  A chart  of  major  considerations  was 
developed  with  sub-charts  delineating  each  major  chart  item. 
It  was  the  conclusion  of  this  effort  that  the  best  method 
for  insuring  an  acceptable  compiler  is  an  acceptable 
specification.  Therefore , a great  deal  of  emphasis  was 
placed  on  compiler  specification  criteria. 

Compiler  acceptability,  therefore,  became  a matter  of 
reviewing  the  items  specified  and  assigning  approptiate 
weighting  scores  which  would  eventually  determine  when  a 
compiler  is  acceptable.  Acceptance  matrices  were  developed 
which  contain  the  major  areas  of  consideration.  These 
matrices  are  to  be  used  to  calculate  an  acceptability 
index.  Sub-matrices  were  developed  for  each  major  item 
within  the  matrix.  A predetermined  sub-matrix  item  weight 
along  with  a user  determined  acceptability  factor  will  be 
utilized  to  calculate  a score.  The  score  will  then  be 
used  as  an  index  into  an  acceptability  chart.  The  Weights 
or  potential  scores  used  are  based  on  sample  matrix 
applications  to  existing  compilers. 
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In  addition  to  the  charts  and  matrices,  examples  were 
developed  which  should  help  the  user  to  make  specific 
choices  according  to  the  desired  meeds  of  a specific 
compiler  system. 


The  form  and  content  of  the  handbook  are  based  on  the 
conclusions  reached  during  the  research  phase  of  the  effort. 
This  included: 

e A wide  range  of  differing  'authoritative'  and 

'expert'  opinions  and  definitions  exist  with  respect 


compiler  components,  processes  and  structure 
compiler  'features' 

compiler  'optimization'  and  'optimizers' 
programming  language  definitional  forms 
operating  system  functional  characteristics 
compiler  efficiency 
measures  of  efficiency 


e A number  of  previous  study  efforts  relating  to 

program  characteristics  of  programs  codtfd  in  higher 
order  languages  support  views  which  are  diametri- 
cally opposed  to  each  other. 


• That  in  all  previous  efforts  significant  and  accurate 


data  has  not  been  accumulated  in  a disciplined 
fashion  within  a 'production*  environment  to  lend 
'authoritative*  credence  to  an  absolute  set  of 
criteria  or  guideline  for  procuring  a compiler. 

e That  subjective  (empirically  developed  over  time) 

'weights'  have  to  be  established  and  assigned  to 
the  following  type  items  in  deciding  what  specifi- 
cations and  requirements  are  to  be  included  in 

procuring  a compiler:  \ 

a.  value  of  human  resources  in  program  develop- 
ment, debugging  and  maintenance  phases . 

b.  value  of  computer  time  used  in  the  compile-  | 

tion  process  and  that  of  the  program  execution  ; 

time.  1 

c.  value  of  linear  time  available  to  a project  or 
installation  (time  required  to  implement  a 
compiler) . 

d.  value  of  the  total  dollar  cost  of  developing, 
debugging  and  maintaining  a compiled  with 
extensive  features. 
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IV.  Future  Efforts — Updating  the  Handbook 

It  became  apparent  at  a very  early  stage  in  the  study  that 
if  the  procuring  agency  stressed  a particular  item  in  its 
specification,  then  all  acceptance  criteria  effected  by 
that  item  would  be  weiqhted  heavily. 

For  example,  if  precise  language  definition  was  stressed 
in  the  specification,  then  the  accuracy  and  reliability 
of  syntax/semantics  analyzers  (acceptance  criteria)  would 
be  heavily  weighted. 

Therefore,  the  sample  Compiler  Acceptance  Evaluation  Matrix 
developed  was  based  on  a hypothetical  "average"  compiler. 
The  values  assigned  represent  composites  of  values  derived 
from  the  analysis  of  several  languages  and  their  compilers. 

• 

The  procuring  agency  should  prepare  a new  set  of  potential 
scores  as  a function  of  language,  project,  user  group  and 
other  constraints  discussed  in  the  handbook.  For  example, 
a file  management  system  written  in  COBOL  would  probably 
not  depend  heavily  on  numeric  accuracy  (past  3 decimal 
places)  or  even  resource  utilization;  but,  it  is  likely 
that  system  interface  would  be  extremely  important. 

It  seems  advisable  that  future  compiler  system  contracts 
include,  as  part  of  the  payment,  an  amount  based  on  the 
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acceptability  score.  This  additional  financial  remuneration 
could  provide  the  incentive  needed  to  turn  acceptable  and 
pood  compilers  into  excellent  compiler  systems. 


EVALUATION 

The  procurement  of  compilers  for  computer  programming  languages  is  an 
important  and  difficult  task.  The  quality  of  the  resultant  compiler  and  the 
aids  it  provides  the  programmer  can  determine  costs  or  savings  that  are  many 
times  greater  than  the  price  of  the  compiler.  Many  government  agencies  that 
do  not  have  expertise  in  the  field  of  compilers  have  requirements  to  procure 
compilers  including  the  specification  and  acceptance  of  these  compilers.  The 
goal  of  the  Compiler  Acceptance  Criteria  Guidebook  effort  was  to  develop  a 
document  that  would  provide  assistance  to  government  agencies  in  the  procurement 
of  compilers. 

Proprietary  Software  Systems,  Incorporated  was  selected  to  develop  guide- 
lines and  to  produce  the  guidebook.  The  guidebook  that  was  produced  contains 
information  that  will  assist  in  the  procurement  of  more  cost  effective  compi- 
lers by  insuring  more  complete  specification  of  the  compiler  and  more  adequate 
criteria  by  which  the  compiler  is  accepted.  Use  of  these  guidelines  should 
result  in  higher  quality  and  more  useful  compilers  with  the  end  result  of  lower 
software  costs. 

DOUGLAS  WHITE 
Project  Engineer 
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INTRODUCTION 


This  document  is  intended  to  be  used  as  a auidebook  in  the 
specification  of  a compiler  system  and  in  the  analysis  of 
its  acceptability.  It  is  divided  into  three  major  parts, 
compiler  specification  criteria,  compiler  acceptance 
scoring,  and  a sample  acceptance  scoring  matrix. 

Part  1 may  be  used  as  a glossary  of  compiler  terminology 
It  should  be  reviewed  carefully  by  the  reader  unfamiliar 
with  these  terms  before  nroceedino  to  parts  2 and  3. 

The  purpose  of  this  document  is  to  aid  the  compiler  pro- 
curement agency.  It  is  a guide  to  the  specification  of 
appropriate  compiler  design,  implementation,  testing  and 
acceptance.  No  attempt  is  made  to  design  or  suggest  a 
universal  set  of  tests  for  all  languages  and  compilers. 

In  many  cases,  automated  verification  systems  already 
exist  for  this  purpose  (JCVF  - JOVIAL  Compiler  Validation 
System) . It  does  suggest  topics  which  should  be  con- 
sidered in  designing  tests  for  a specific  project  and 
indicates  usual  results  of  importance.  The  weighting 
factors  assigned  in  Part  3 are  based  on  "sample"  systems 
and  compiler  requirements  and  are  by  no  means  fixed. 

Each  agency  must  assign  its  own  weights  and  relative 
importance  to  each  item.  The  sample  weights  are 
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hypothetical  guidelines  to  help  each  procurement  agency 
to  develop  its  own  historical  specification/acceptance 
criteria. 

Part  1,  Compiler  Specification  Criteria , provides  respon- 
sible individuals  with  a means  of  identifying  the  features 
and  facilities  a compiler  system  should  contain  to  best 
utilize  its  available  resources  within  the  necessary  budget 
and  time  constraints.  A chart  of  major  considerations  is 
provided  with  sub-charts  delineating  each  major  chart  item. 

It  was  the  conclusion  of  this  effort  that  the  best  method 
for  insuring  an  acceptable  compiler  is  an  acceptable 
specification.  Therefore,  a great  deal  of  emphasis  is 
placed  on  Part  I,  Compiler  Specification  Criteria. 

Part  2,  Compiler  Acceptability,  reviews  the  items  specified 
in  Part  1 and  assigns  appropriate  weighting  scores  which 
will  eventually  determine  when  a compiler  is  acceptable. 

The  acceptance  matrices  are  provided  which  contain  the  major 
areas  of  consideration.  These  matrices  are  used  to  calculate 
an  acceptability  index.'  Sub-matrices  are  provided  for  each 
major  item  within  the  matrix.  A predetermined  sub-matrix 
item  weight  along  with  a user  determined  acceptability 
factor  is  utilized  to  calculate  a score.  The  score  is  then 
used  as  an  index  into  an  acceptability  chart.  The  weights 
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or  potential  scores  used  in  Parts  2 and  3 are  based  on 
sample  matrix  applications  to  existing  compilers. 

In  addition  to  the  charts  and  matrices,  examples  are 
provided  which  help  the  user  to  make  specific  choices 
according  to  the  desired  needs  of  a specific  compiler 
system. 
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Part  3,  the  sample  Acceptance  Scoring  Matrix  is  a 
summarization  of  the  topics  discussed  in  Part  2.  In  this 
matrix,  the  acceptance  items  are  listed  with  the  corres- 
pondino  weighting  factors  appropriately  broken  down  into 
sub-matrix  form. 

It  should  be  noted  that  the  specification  and  eventual 
acceptability  of  a compiler  system  is  a complex  process. 
This  guideline  establishes  an  orderly  approach  in  deter- 
mining the  specification  and  acceptability  criteria  for 
a compiler  system.  It  thereby  helps  to  insure  a thorough 
and  objective  decision-making  process  when  selecting  a 
compiler. 
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Part  1 Compiler  Specification 

The  acquisition  of  a compiler  system  often  represents  the 
most  critical  aspect  in  the  development  of  a successful 
software  system.  Heretofore,  virtually  no  guidelines 
were  provided  for  buyers  to  facilitate  the  specification 
of  a new  compiler. 

Software  development  involves  many  considerations.  The 
selection  of  the  appropriate  language  tools  in  the  deve- 
lopment process  is  not  only  critical,  but  will  have  major 
effects  in  terms  of  cost,  development  time,  efficiency, 
portability,  and  ease  of  maintenance  and  modification. 

Minimizing  programming  errors  often  depends  a great  deal 
on  matching  the  complexity  of  the  application  with  an  appro- 
priate programming  language.  Many  variables  should  be  con- 
sidered when  deciding  on  the  features  of  a particular 
system. 

The  charts  on  the  following  cage  present  the  major  areas 
of  concern  when  specifying  a compiler.  Each  item  is  then 
further  delineated  in  subseouent  sub-charts.  Ml  items 
in  the  sub-charts  are  discussed  as  to  their  relative  merit 
in  the  acquisition  of  a compiler  system. 
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1.1  Compiler  Costs 
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Of  primary  concern  in  the  acquisition  of  a compiler  is 
the  "actual"  dollar  cost,  fince  the  cost  associated  with 
a compiler  system  involves  the  original  investments  as 
well  as  other  significant  on-going  expenditures,  the 
topic  of  "actual"  cost  becomes  increasingly  complex. 

Usually,  the  compiler  procuring  agency  is  only  concerned 
with  the  initial  "out-of-pocket"  outlay.  The  following 
chart  and  subsequent  explanations  may  help  the  compiler 
specification  writer  to  develop  insights  into  "actual" 
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• Purchase  Price 

P major  consideration  in  the  acquisition  of  any  item 
is  the  purchase  price.  Although  the  purchase  price  is 
almost  always  not  part  of  a compiler  specification, 
it  is  often  specified  indirectly  (in  terms  of  man-hours 
and  job  classifications) . Virtually  all  items  delin- 
eated in  the  specification  charts  have  a direct  bearing 
on  the  purchase  price. 

The  compiler  specification  writer  should  investioate 
the  relative  costs  and  benefits  of  the  features  under 
consideration.  This  will  assure  the  most  effective 
usage  of  the  available  resources.  The  relative  merit 
of  a special  or  "extra"  feature  must  be  analyzed  in 
relation  to  its  added  cost  in  order  to  maximize  the 
utility  of  the  compiler  system. 

It  is  very  common  in  the  development  of  a compiler  system 
to  have  progress  payments  made  as  the  contract  proceeds. 
This  is  usually  due  to  the  large  expenditure  of  labor 
and  computer  time  often  necessary  to  complete  a compiler 
project.  It  is  highly  improbable  that  any  software 
organization  specializing  in  compiler  implementation 
would  be  willing  or  able  to  work  for  long  periods  with- 
out financial  reimbursement. 
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Since  compiler  system  contracts  are  usually  fixed  price, 
as  opposed  to  time  and  materials,  it  is  advisable  to 
identify  milestones  at  which  point  partial  funds  might 
be  made  available  to  the  developing  agency.  Progress 
payment  provisions  relating  directly  to  partial  product 
deliverables  have  to  be  carefully  constructed  to  insure 
that  the  balance  of  funds  flowing  to  the  vendor  is 
aoproximately  equal  to  the  value  flowing  back  to  the 


user.  In  this  manner,  project  termination  will  not 
create  major  hardships  for  either  party. 


Specific  items  include: 

• Pasic  compiler  (software)  purchase  price 

• option  prices 

j 

• Advances 

• Milestones 

1 

• Test  of  Compilation 

A major  cost  that  is  usually  ignored  in  the  specifi- 
cation of  a compiler  is  the  cost  of  compiling  a prograr. 

Individual  compiler  implementations  of  the  same  corpiler 
specification  can  have  vastly  different  costs  associated 
with  the  translating  of  a proerram.  j 

Part  of  any  compiler  specification  should  contain  a j 

maximum  cost  per  specified  test  program.  The  test  i 
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[ is  the  compiler's  operation  during  large  compilations. 

[ I Often  a compiler  will  perform  well  for  small  modules  but 

' i 

will  run  slowly  when  reaching  certain  “intrinsic  limits." 
Too  often  compiler  buyers  have  neglected  this  area  and 
>’  have  received  a compiler  that  met  all  specifications, 

‘ yet  was  of  little  practical  value. 


Pnecific  items  include: 

e small  program  costs  per  statement 
e large  program,  costs 
e medium  or  average  costs 
e overhead  costs 


t 
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e Cost  of  Fxecution 


The  code  generated  by  a compiler  and  the  tools  provided 
to  improve  the  efficiency  of  the  code  can  be  vital  in  the 
overall  effectiveness  of  the  compiler  systems.  A compiler 
system  is  merely  a tool  to  be  used  in  the  development  of 
software. 

*phe  intended  application  of  programs  generated  by  a 
compiler  coupled  with  the  expected  life  of  the  compiled 
program  (number  of  times  to  be  used)  can  often  make 
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this  aspect  the  most  critical  of  all  cost  items.  Depending 
on  the  Darticular  anplication,  the  erudite  writer  of 
compiler  snecif ications  should  include  some  minimum 
acceptable  ratio  of  compiler “code -generated  execution 
cost  versus  the  execution  cost  of  an  identical  machine 
language  program  v’ritten  by  an  above  average  programmer. 

It  should  be  noted  that  the  term  execution  cost  implies 
not  only  execution  time,  but  also  computer  resources 
utilized  by  the  compiled  program  (memory,  disk,  I/O 
access,  etc.).  This  may  be  handled  in  a small,  medium, 
laroe  program  fashion  as  for  compilation  costs.  Specific 
items  of  concern  are? 

e CPU  time  per  statement  or  program 
e core  usaere 
e I/o  access  time 
e wait  or  dead  ti^e 
e disk  storage 
e tape  drive  mounts 
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In  large  computer  systems  there  will  often  be  a machine 
unit  cost  of  execution  formula  which  may  be  used  for 
computing  total  cost.  This  may  be  quite  complex 
and  is  left  to  the  specification  agency  discretion.  A 
prime  example  is  the  OS  370  HAeP  system. 
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• Level  of  Expertise 

Another  often  neglected  cost  item  is  the  "quality"  of  the 
compiler  system  as  a major  determining  factor  in  the  level 
of  expertise  required  by  users.  The  relative  time  it  takes 
to  get  a job  done  is  usually  directly  related  to  the  level 
of  the  language  (assembly-higher  level-SDecial  purpose) 
and  its  features. 

If  a junior  level  programmer  can  accomplish  the  productivity 
of  a senior  level  programmer  because  of  the  compiler 
system's  lanouage  and  features,  then  the  dollars  saved 
become  a major  cost  factor.  The  quantitative  analysis  and 
relative  merit  of  new  features  is  very  important  to  the 
future  costs  associated  with  the  compiler's  usage. 

• Pesource  Utilization 

It  is  not  at  all  uncommon  for  the  vendor  to  require  the 
usaae  of  resources  supplied  by  the  procuring  agency.  At 
a minimum  these  resources  will  probably  include  the 
participation  of  staff  in  both  the  design  concept  and 
during  the  compiler  acceptance  approval  cycle. 

It  is  quite  common  for  the  buying  organization  to  supply 
machine  time  for  the  development,  checkout,  and  installation 
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of  the  compiler  system*  In  addition,  other  resources  are 
often  provided  in  terms  of  office  space,  telephones, 
secretarial  services,  keypunching,  etc.  Thus,  it  is 
necessary  to  stipulate  what  types  of  resources  will  be 
supplied  by  the  procurincr  aoency. 


If  the  maximum  level  of  resources  is  exceeded, 
then  the  specification  should  state  the  consequences 
(charges) . This  will  insure  that  excessive 
resource  utilization  will  be  minimized  by  the  vending 
organization. 

On  the  other  hand,  very  stiff  penalties  may  result  in 
inadequate  testing,  or  non-optimized  code  generation. 
Resource  expenditures  should  be  as  liberal  as  possible 
to  insure  effective,  on-time  deliveries.  Low  resource 
costs  usually  may  he  obtained  by  use  of  slow  turnaround, 
low  priority  computer  usage  and  subsequent  schedule  delays, 
therefore,  resource  availability  is  also  of  primary  concern. 

• Resource  Acquisition 


Tn  some  cases  it  may  be  necessary  for  the  Drocurinn 
agency  to  purchase  additional  hardware  to  facilitate 
the  development  or  use  o*  a compiler  system. 
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In  general,  the  procuring  agency  must  determine  the 
resources  to  be  provided  in  advance  of  contract  negotia- 
tions or  even  PFP  preparation.  Appropriate  responses 
should  include  a statement  of  resources  recruired  in 
addition  to  those  listed  in  the  RFP.  f’ardvare  items 
most  likely  to  be  critical  in  compiler  utilization  are: 

• Core  storage  (fast) 

• t’ser  interface  devices  (printer,  CRT,  card  readers) 

• Intermediate  I/O  (modems,  multiplexors) 

• Secondary  storage  devices  (disk) 

Proper  allowances  must  be  made  for  these  items  to 
insure  a compiler  system  which  will  be  available  to  the 
maximum  number  of  users  over  a full  range  of  applications. 

• Maintenance  Costs 

The  compiler  specification  should  contain  a provision  for 
vendor  maintenance  after  acceptance.  The  maintenance 
period  should  extend  for  the  useful  life  of  the  product. 

A heavily  used  compiler  will  become  reliable  within  a 
short  period  of  time. 

In  this  case,  a front-loaded  maintenance  budget  is 
recommended.  In  oeneral,  the  vendor  should  be  required 
to  supply  the  first  year's  maintenance  as  oart  of  the 
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compiler  development  costs.  A typical  maintenance  budget 
is; 

Years  After  Acceptance  Percentage  of  Development  Cost 


0-1 

0 « 

1-2 

20% 

2-Life  of  the  Product 

10% 

This  is  subject  to  the  choice  of  vendor  (reputation  and 
location) , complexity  of  the  language/pro ject , time 
schedule  for  implementation , and  previous  experience. 

• Enhancement  Costs-Pptions 

The  compiler  PFO  should  explicitly  require  fixed  price 
estimates  for  enhancements  and  additions  to  the  basic 
svstem.  Items  to  consider  include: 

• Debuo  packages 

• Optimization  routines 

• Language  extensions 

• Training  Costs 

Initial  procuring  agency  personnel  training  and  education 
costs  should  be  included  in  the  vendor  proposals  at  a very 
low  cost.  Training  includes  proner  documentation  of  the 
language,  compiler  usage  and  program  listings.  Additional 
specifications  for  later  training  of  other  vendors/users 
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of  the  compiler  must  be  included.  Too  often,  an  agency 
becomes  dependent  on  a particular  vendor  for  subsequent 
acquisitions.  Usually,  this  is  because  the  aoencv-owned 
comoiler  cannot  be  altered/maintained  by  other  vendors. 
The  original  vendor  must  be  required  to  accept  responsi- 
bility for  training  in  subsequent  installations  as  well. 

• Pe-targeting  Costs 

The  compiler  specif ication  must  include  provisions  for 
additional  target  computer  implementation,  ^he  cost 
proposals  should  include  vendor  costs  estimates  for  the 
full  implementation  and  costs  for  training  of  other 
vendor  personnel,  mfte  specification  should  require  an 
absolute  minimum  cost  fo^  re-targeting  and  concommitant 
advanced  technology.  The  code  generator  or  target 
dependent  portion  of  the  compiler  should  be  one  of  the 
least  expensive  to  duplicate. 

• Re-hostinq  Costs 

Pe-hosting  is  the  process  of  moving  the  compiler  system 
to  a new  computer  without  changing  the  result  or  outout 
(target  programs)  . The  vendor  should  be  reouired.  to 
prepare  cost  quotations  for  every  major  host  svstem  to  be 
used  by  the  procurino  anency  and  major  civilian  companies 


I 


The  re-hosting  costs  should  include  estimates  for  original 
and  new  vendor  implementations. 


1.2  Language  Definition 


The  most  important  part  of  any  compiler  system  is  its 
ability  to  properly  translate  each  specified  language 
form  to  obtain  the  eventual  execution  of  the  compiled 
program.  The  specification  of  the  features  of  a compiler 
lanouaoe  should  be  as  clear  as  possible  in  order  to  avoid 
any  misinterpretations. 

Several  mathematical  languages  have  been  developed  that 
facilitate  the  specification  of  compiler  features. 
Pelatively  accepted,  mathematically  oriented  languages,  such 
as  Fackus  Nauer, already  exist  for  this  purpose.  In 
addition,  it  is  also  advisable  to  have  a brief  English 
explanation  of  the  various  language  components.  The 
clarity  of  syntax  and  semantic  representation  is  of 
utmost  importance  to  the  compiler  implementor  as  well  as 
the  eventual  user. 

In  order  to  eliminate  any  ambiguities  or  misunderstandings 
the  definition  of  a new  computer  languages'  format  must 
be  defined  as  clearly  and  concisely  as  possible.  Meta- 
linguistic syntactic  definitions  have  been  developed  in  a 
complete,  efficient,  and  concise  form.  In  fact,  the 
success  of  these  definitions  can  be  judged  from  the 
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diversity  of  lanouage  descriptions  that  have  been 
developed  from  a meta-linguistic  notation. 

The  language  in  which  the  compiler  is  defined  is  tenred  a 
meta  lanouage.  The  meta  lanouaoe  must  be  uniquely 
distinguishable  from  the  language  being  described.  The 
following  chart  lists  the  items  of  a compiler  lanouage 
vrhich  should  be  defined  in  both  a meta  language  as  well 
as  in  a prosaic  manner. 

If  the  languaoe  to  he  specified  already  exists  in  other 
environments,  then  it  is  highly  likely  that  a formal 
reta-linguistic  mathematical  specif ication  is  already  in 
existence.  Popular  languages  such  as  Fortran,  COPOL,  BASIC, 
ALC.OL,  PI./l,  and  JOVIAL  have  all  been  defined  via  vigorous 
notations.  Aspects  of  most  languaoes  can  be  cateoorized 
and  described  as: 

Syntax  Characteristics 
Declarative  Statements 

Control  Statements 

Subroutine  Statements 
Processing  Statements 
Allocation  Statements 
Input/Output  Statements 
Formating  Statements 
Compiler  Directives 


• Syntax  Characteristics 
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The  specification  of  a compiler  would  be  meaningless  with- 
out a formal  description  of  the  language  to  be  translated. 
The  syntax  rules  for  the  followino  items  should  be 
included  in  the  specification: 
e Character  Set 
e Symbol  Construction 
e Keywords 

e Statement  structure 
e Comments 

e Statement  Termination 
e Variables 
e Logical  Operators 
e Relational  Operators 
e Arithmetic  Operators 
e Expressions 
e Literals 
e Functions 
e Constants 

e Declarative  Statements 

The  declarative  statements  specify  the  variables  that 
will  be  used  in  writing  a program.  Often,  the  declara- 
tion statement*  include  information  that  describes 
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attributes  of  the  variables. 

• Control  Statements 

Control  statements  control  the  program  flow.  Transfer 
statements,  conditional  statements,  switch  statements, 
iteration  statements,  and  decision  table  statements 
are  examples  of  control  statements. 

• Subroutine  Statements 

Subroutine  statements  provide  a meanB  of  modulari2ina  a 
program.  Usually  these  statements  include  facilities  for 
declaring  a subroutine,  referencing  a subroutine,  and 
exiting  a subroutine.  In  addition,  subroutines  often 
have  the  capability  of  passino  arguments. 

• Assignment  Statements 

Assignment  statements  provide  a means  of  assignino 
values  to  variables. 

• Allocation  Statements 

Allocation  statements  control  the  Dlacement  of 
variables  in  memory.  In  addition,  allocation  statements 
declare  the  dimension  of  variables.  In  some  languages 
the  declaration  statements  perform  some  of  the 
functions  of  the  allocation  statements. 
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j • Input  Output  Statements 

| " Input  output  statements  provide  a means  of  getting 

information  into  and  out  of  a computer.  The  capability 
! to  describe  the  devices  is  included  in  some  languages. 

• Formating  Statements 

Formating  statements  describe  the  format  of  data  to  be 
read  into  or  out  of  a computer. 

! • 

i 
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1.3  Compiler  Options 


* 
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There  are  a myriad  of  capabilities  and  facilities  that 
a compiler  may  possess  or  influence  with  respect  to  a 
modern  computer  system.  This  guidebook  assumes  that 
compiler  requirements  among  different  installations  are 
widely  divergent.  This  is  especially  true  when  selections 
are  based  on  a maximum  utilization  of  available  resources. 

The  following  chart  and  subsequent  explanations  define 
numerous  capabilities  and  facilities  which  improve  the 
utility  of  a compiler  system.  Assignments  are  made  for 
expected  dollar  benefit  versus  anticipated  costs  of  each 
compiler  option.  This  eases  the  choice  of  items  to 
include  in  the  specification. 
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Subsets/Special  Versions 


optimizations 
Measurement  Tools 


Pebuo  Aids 


.Test  Aids 

Documentation  Aids 


Cross  Peference/Dictionaries 
Fource  Libraries 


Compools 


'’’ext  Maintenance 


Directives 


Detailed  Diagnostics 


Peformatters 


standard  Verification 


Fource  Listings 


Partial  Compilations 


COMPILFR  FPFCIFICATION  - COMPILER  OPTION? 
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• Compiler  Types 

The  purpose  for  which  a compiler  will  be  used  and  the 
intended  amplications  for  which  proqrams  will  be  develoned 
all  have  an  impact  on  compiler  type. 

• PATCH 

BATCH  compiler  requires  all  input  files  to  be  supplied 
before  compilation.  This  is  the  most  popular  irnplemen- 
tation  type  for  compilers.  It  provides  for  t£e  most 
efficient  means  of  minimizing  the  cost  per  compilation. 

• COHVEPFATTOHAL/INCREMFMTAL 
The  CONVFFFATIONAL  compiler  communicates  with  the  user 
throughout  the  translation  process.  The  user  can 
continually  make  correction/modifications  as  the 
compiler  translates/executes  the  users'  program.  R 
conversational  compiler  is  usually  very  effective  for 
the  development  of  a program  where  compilation  cost  is 
not  very  important. 


• INTFPPPETIVF 

An  INTFFPPFTIVF  compiler  performs  the  execution  of  a 
program  directly  rather  than  preparino  an  object  version 
of  the  program  to  be  executed  later.  An  interpretive 
compiler  usually  generates  less  efficient  object  code 


1-21 


\ 


A 


r 


but  minimizes  compilation  time  and  re-targeting  tasks. 

• Pubsets/er>ecial  Versions 

’’’’he  primary  motivations  for  subsettino  are  cost  and  time. 
Cutsets  permit  smaller  compilers  which  can  be  developed 
more  economically  and/or  in  less  time.  It  is  important 
that  a subset  be  a "proper”  subset  to  insure  upward  com- 
patibility. 

often  a comniler  of  an  already  existino  language  is 
specified  as  a prorer  subset  exceot  for  several  ''soecial" 
features.  These  'subset  versions"  special  features  may 
be  more  costly  (in  terms  of  oompatiM)  ity  and  transfera- 
bility) than  the  benefits  they  provide. 

• optimization 

over  the  la.st  two  decades  numerous  techniques  have  been 
developed  to  improve  the  efficiertv  of  code  generated 
by  compilers.  Usually  these  optimization  features  are 
divided  into  local  and  global  optimization.  The  cost 
associated  with  develooinn  optimization  facilities  for  a 
compiler  can  usually  be  divided  into  two  areas:  additional 
development  costs  and  more  costly  compilation. 
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Normally,  if  sophisticated  optimization  facilities  are  to 
be  developed,  it  is  advisable  that  they  be  conditional  and 
? selective.  For  example,  it  is  not  usually  necessary  to 

optimize  application  programs  during  their  development 
» cycle.  In  addition,  numerous  studies  have  shown  that 

i 

small  portions  of  a program  usually  consume  the  majority 
1 of  a program's  execution  time.  Hence,  ODtimization  of 

\ selected  areas  usually  proves  the  most  effective  in  terms 

I of  cost/benefit  ratio. 

,1  There  are  often  several  alternatives  to  expensive  optimiza- 

tion facilities.  These  include  measurement  facilities 
which  pinpoint  areas  to  be  optimized  and  facilitate 

t 

> interfacing  to  assembly  language  programs.  Each 

optimization  facility  should  be  weighed  in  terms  of  cost/ 

* benefit  ratio. 

i 

> i 

Local  optimization  features  are  usually  less  expensive 
than  global  optimization  facilities.  The  following  is  a 
list  of  potential  local  optimization  facilities: 

• Peordering  of  the  evaluation  of  an  expression 

• Efficient  use  of  registers  and  memory 

• Common  expression  elimination 

• Redundant  statement  elimination 

• Dead  variable  elimination 
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• Factoring  (eg.  A*B+A*C  to  A*(B+C)) 

• Constant  evaluation 

• Petarnet.ino  of  jumos  (pa.  ooto  l2  becomes  comp  13 
if  T2  contains  a OO'T'o  l3) 

• Flimination  of  redundant  stores 

• rfficient  utilization  of  target  machine  instructions 

"he  follov’ina  is  a list  of  global  optimization  facilities* 

• Flow  analysis  - this  is  usually  a very  costly 
optimization  technique.  Its  benefits  involve  the 
re-ordering  of  statements  and  the  elimination  of 
unnecessary  statements.  Manv  of  these  benefits  can 
also  be  attained  through  proper  programmina  techniques 
bv  the  user. 

• Elimination  of  assignina  a.  variable  to  an  expression 
that  is  never  used. 

• Pase  register  versus  active  reoister  usage. 

• Code  redistribution  - moving  code  segments  to  a 
oath  that  eliminates  redundant  execution. 

• Measurement  Tools 

Measurement  tools  are  an  invaluable  asset  in  improving  the 
performance  of  a compiler  system.  There  are  three  basic 
areas  of  potential  improvement  that  measurement  systems 
can  be  used  in  a compiler  system.  These  are: 
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• Measurements  to  improve  the  language  itself, 
e Measurements  to  improve  the  performance  of  the 
compiler's  operation. 

e Measurements  to  improve  the  performance  of  programs 
that  have  been  compiled. 

Usually  measurement  facilities  can  be  built  into  a 
compiler  at  a fraction  of  the  cost  of  optimization 
features.  It  is  recommended  that  these  facilities  be 
both  optional  and  selective. 

i 

The  gathering  of  statistics,  such  as  features  used; 

1 

combinations  of  statements;  and  frequent  user  errors  . 

provide  valuable  insights  to  language  designers  in  | 

terms  of  improving  the  utility  of  the  language. 

Statistics  regions  help  pinpoint  areas  to  be  optimized. 

. * These  statistics  can  point  out  vital  areas  of  the 

compiler/application  program  that  should  be  optimized.  1 

i ' I 

e Debug  Aids  * 

One  of  the  major  purposes  of  a higher  level  language  is 
to  simplify  the  cost  of  developing  and  maintaining  programs. 

Debug  aids  are  indispensable  tools  in  the  checkout  of  new 
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programs/modifications  or  in  the  location  and  eventual 
correction  of  problems.  The  following  is  a list  of  debug 
aids : 

• Corrections 

The  ability  to  modi*v  object  Droorams  without 
having  to  recompile  saves  both  dollars  and  time. 

• Snanshots/Dump 

'’’he  displaying  of  variables  in  a format  that  is 
compatible  with  the  language  is  very  beneficial. 

• Item./Locaticn  ’Modification 

The  facility  of  being  able  to  see  a variable's 
modification  at  a particular  location  (routine, 
statement  number)  is  extremely  helpful  in  the 
checkout  of  a program. 

• Traces 

The  display  of  sequences  of  program  instructions 
(especially  symbolically  coupled  with  iter  modifi- 
cation) is  useful  for  efficient  program  checkout. 

• Conditionality 

The  ability  to  invoke  the  above  features  conditionally 
is  a very  powerful  program  development  methodology. 


' The  generation  of  test  programs  to  verify  the  "correctness" 

of  a set  of  programs  is  a major  consideration  when  develop- 
ing a system.  In  the  last  decade  tools  have  been  developed 
which  aid  the  generation  of  test  piograms. 

j Intrinsic  to  these  tools  is  a flow  analysis  of  the  program 

» 

to  be  tested.  Since  compilers  must  make  a like  analysis 
j during  global  optimization,  several  compiler  systems  now 

include  the  preparation  of  test  programs  as  an  integral 
part  of  the  system. 

• Documentation  Aids 

The  facility  for  effectively  interjecting  program  comments 
into  the  source  program  is  of  utmost  importance.  It  is, 
however,  an  inteoral  part  of  the  language  definition  and 
not  an  option.  The  compiler  may  be  used  to  enhance  this 
feature  by  specially  formating  printing  of  conments, 

i 

automatically  indenting  loop  structures,  and  summarizing 
classes  of  variables  and  statements  used.  ?*anv  of  these 
aids  are  traditionally  suoolied  via  the  cross-reference 
facility. 
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• Cross  Peference/Dictionaries 

Most  compilers  will  output  an  alphabetized  symbol  table 
(dictionary)  at  the  conclusion  of  each  nodule.  The 
dictionary  provides  an  easv-to-use  reference  to  the 
tvpe  and  value  associated  with  each  user  declared  variable. 

A cross  reference  provides  a neans  of  identifyinn  where 
each  variable  is  referenced  in  a Particular  rodule.  This 
facility  is  a very  important  asset  in  the  development  and 
maintenance  of  nroarams.  Tn  lanctuages  such  as  JOVIAL  the 
scope  of  each  variable  is  also  of  utmost  importance  and 
can  be  further  emphasized  here. 

• Fource  Libraries 

often,  an  application  will  contain  a set  of  programs  with 
identical  source  statements  (usually  declarations) . It 
is  both  more  economical  and  less  error  prone  to  be  able 
to  reference  a set  of  source  from  a single  statement 
rather  than  including  the  same  source  in  numerous 
modules. 

• Comnools 

oompools  provide  a reans  of  gathering  cornon  variable 
definitions  into  a sincle  file.  Compools  usually  differ 
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from  source  libraries  in  that  they  have  been  ©retranslated 
and  exist  in  a more  readily  accessible  form.  Usually  a 
language  that  facilitates  compools  has  specific  rules 
regarding  undefined  variables  in  a program  and  their 
accessability  from  the  compool. 

• Text  Maintenance 

Text  maintenance  provides  an  efficient  means  of  maintain- 
ing and  modifying  a source  program.  Nearly  all  major 
computer  systems  already  contain  text  editors  and  source 
maintenance  programs.  If  neither  of  these  are  available, 
the  compiler  system  should  contain  a facility  for  up- 
dating source  files. 


• Directives 

Directives  provide  a means  for  the  user  to  auide  the 
compiler  in  performing  a particular  compilation.  The 
utility  of  the  directives  depends  on  the  application  to  be 
performed  and  the  function  of  the  directive.  The 
following  is  a brief  list  of  some  of  the  directives  which 
might  be  included: 

• Macro  - A set  of  directives  which  permits  the  user 
to  define  new  facilities  in  terms  of  existino 
facilities.  This  facility  can  make  the  language 
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more  flexible  to  future  needs  (but  ray  cause 
future  corpatibility  prohlers) . 

• Conditional  - A set  of  directives  that  determines 
which  statements  are  to  be  compiled.  This  allows 

a source  nrearar  to  adapt  to  different  environrents 
based  on  nredefired  conditions. 

• ootirization  - ^ set  of  directives  allowing  the 
user  to  specifv  which  areas  to  optimize  and  the 
ratio  of  sneed  versus  space  considerations. 

• **ode  - > set  of  directives  which  influences  the 
type  of  code  to  be  aenerated  (ec?.  whether  or  not  a 
subroutine  is  to  be  re-entrant) . 

• Detailed  Diagnostics 

"he  level  of  information  provided  by  a compiler  for  error 
messaoes  is  extremely  important.  The  ability  of  the 
comniler  to  pinnoint  the  reason  for  the  error  is  vital  to 
the  efficient  development  of  software. 

Tt  is  '.inadvisable  (unless  other  constraints  prevail)  to 
have  the  compiler  lump  numerous  error  messages  into  a 
sinole  category.  Tt  is  also  useful  to  have  a diagnostic 
summary  at  the  conclusion  of  each  module. 
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• Reformatters 

A reformatter  rearranges  the  display  of  a source  program. 
This  is  useful  if  previous  or  present  programs  are  being 
developed  that  do  not  use  any  standardization  in  terms  of 
source  arrangerent. 

• standard  Verifications 

Often  a department  will  develop  a set  of  "good  Drogramming 
■ standards."  Included  in  these  standards  might  be 

4 structured  programming  concepts,  variable  identifier 

rules,  etc.  It  is  beneficial  to  management  if  the 

* compiler  system  contains  facilities  for  monitoring  and 

renortincr  any  exceptions  to  the  standards. 

• Source  Listings 

I 

> A compiler  will  usually  list  the  source  program  it  has 

translated.  It  is  often  helpful  if  the  user  can 

• optionally  obtain  an  assembly  listino  expansion  of  his 

source.  If  an  assembly  listinn  is  provided,  then  it  is 
extremely  beneficial  if  there  is  some  direct  correlation 
between  user  defined  variables  and  the  variable  na*"es 
generated  by  the  compiler.  This  makes  the  assembly  code 
considerably  more  readable.  In  addition,  such  things  as 
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location,  object  and  sequer.ee  numbers  should  be  included 
to  aid  the  programmer  in  developina/maintaining  his  or 
her  nroerram.  It  is  also  usually  beneficial  if  the 
assembly  listinq  is  interspersed  with  the  compiler  source 
listina.  "’itles,  dates  of  corpilation,  nroorammers  nane, 
and  similar  items  should  also  be  provided  in  the  listing. 

• Partial  Compilations 

h martial  compilation  facility  allows  the  proarammer  to 
control  the  behavior  of  the  compiler.  Often  a compiler 
is  implemented  as  multiple  passes  through  a source  file 
(or  an  intermediate  lanauaqe  translation  of  the  source) . 

* developer  of  a new  procra*'  ray  only  desire  a listiro  o* 
his  source  and  any  syntax  errors  that  exist.  It  is  often 
possible  to  accomplish  this  task  with  a fraction  of  the 
time/cost  normally  required  for  a complete  corpilation. 
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A comniler  is  extensible  if  it  can  easily  be  modified 
to  include  nev  features.  In  general,  a compiler  that 
is  implemented  usinn  "good  programming  practices," 
(structured  programming,  top-down  desion,  srall  modules, 
etc.)  is  usually  readily  modifiable  for  future  require- 
ments . 

If  a new  language  is  beino  implemented , or  an  existing 
language  is  expected  to  be  modified,  it  is  advisable 
that  the  specif ication  include  an  "onen-end"  design. 

''’he  following  chart  depicts  items  which  are  essential 
to  a compiler  system's  extensibility: 

Modularization 

^pen-Fnd  He si on 

"’on-down  Pesign/Ftructurod  Programming 

Mininal  Cser  Pestrictions/Compiler  Limitations 
Parameterization ; 

CO»*PITFP  SPECIFICATION’  - FYTFVFIPILITY 
Modularization 

mhe  idea  of  breaking  a programming  system  into  rfmall 
modules  not  onlv  benefits  program  checkout  and  maintenance, 
but  it  also  makes  the  compiler  easier  to  modify  for  future 
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requirements.  A complex  compiler  system  requires  numerous 
functions.  It  is  quite  conceivable  to  find  in  excess  of 
150  distinct  modules  for  a veil  structured  compiler  system. 
Tt  is  certainly  advisable  that  the  soeci f ication  contain 
a statement  that  the  comniler  consist  of  multiple  modules 
and  that  no  module  should  be  more  than  some  finite 
number  of  statements. 

e ooen-Fnd  Design 

V’hen  designing  a comniler  system,  data  structures  are 
develoned.  vhich  are  used  to  retain  such  information  as 
variable  type,  variable  dimensions,  name  scone,  error 
directories,  cross  references,  and  literals.  In  addition, 
internal  translations/parsing  of  source  often  build 
intermediate  lanouage  forms  vith  character  strinas 
renlared  by  nureric  representati ons . 

Tt  is  crucial  that  the  comniler  designer  "leave  room"  for 
future  entities  if  extensibility  is  to  be  meaningful. 

For  example,  assume  3 bits  are  allotted,  throunhout  the 
intermediate  language  to  designate  type  of  operation, 
further  assume  the  follovino  eight  entries  already  exist: 
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Operator 

Pinary 

Representation 

Meaning 

+ 

000 

Add 

- 

001 

Fubtract 

* 

010 

Multiply 

/ 

Oil 

Divide 

& 

300 

Logical  And 

1 

101 

Logical  Or 

110 

Logical  Not 

% 

111 

Logical  Exclusive  Or 

('  Nov  assune  that  the  usage  of  these  three  bits  is 

scattered  through  nunerous  nodules.  Tf  it  later  becones 
¥ desirable  to  add  several  nev  operators  (eo.  exponentiation , 

relationals,  etc.),  it  night  be  extrenely  difficult,  ''’his 
would  especially  be  true  if  the  three  bit  iten  vas  con- 

* tained  in  a structure  which  had  no  additional  or  unused 

> space. 

• Top-Down  Pesicn/Ftructured  Progran 

• 

A top-dov/n  design  usually  allows  for  the  sinpler  under- 
• standing  of  the  basic  flow  of  the  syster.  Coupled  with 

structured  prograrrino,  the  basic  logic  of  the  syster 

is  not  only  nore  naintainable  hut  also  easier  to  nodify 

for  future  reguirenents . 1 
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Minimal  User  Pestrictions/Compiler  Limitations 

Often  compilers  are  implemented  with  fixed  limits  in 
terms  of  items  such  as  the  number  of  symbols,  number  of 
records  per  source  statement,  and  number  of  parentheses  in 
an  expression.  Usually  these  limitations  are  a result  of 
poor  design  techniques  and/or  inadequate  use  of  the  proper 
data  structures. 

Stacks,  circular  queues,  variable  length  arrays,  pointers, 
and  generally  well  designed  data  structures  will  minimize 
the  number  of  compiler  limitations  and,  hence,  user 
restrictions.  Minimization  of  restrictions  is  very 
crucial  to  compiler  extensibility. 

Parameterization 

Parameterization  is  a method  whereby  a program  may  easily 
he  adjusted  to  accept  new  program,  hardware  or  system 
attributes  or  restraints.  It  is  extremely  important  that 
values  which  define  arbitrary  limitations  be  parameterized. 

The  compiler  implementation  language  should  definitely 
include  a facility  for  parameterization.  The  compiler 
specification  should  require  the  usage  of  this  feature. 

Pee  the  following  section  on  transferability  for  a more 
detailed  discussion  of  parameterization. 
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Trans^erabil itv  is  a Treasure  of  the  ease  of  movinq  a 
computer  program  fro r one  computing  environment  to 
another,  ^ransferabilitv  vith  respect  to  a compiler 
system  can  be  divided  into  two  major  areas:  the  movement 
of  the  compiler  to  a nev*  host  computer,  and  the  gene- 
ration of  object  code  for  a different  taraet  computer. 

These  tvo  areas  represent  substantially  different 
| problem  areas,  althouah  there  is  considerable  overlap 

involved  vith  both.  Tf  it  is  intended  tor  the  compiler 
to  operate  on  multiple  hosts  or  more  than  one  taraet, 
then  the  specification  should  contain  a future  option 
renuirinc  the  desired  tash. 

I 

usual  judoement  of  the  desireability  of  any  transfer 
effort  or  technique  is  its  cost  effectiveness.  foeci 
ficallv,  the  fiaure  of  merit  is  the  cost  per  transferred 
unit.  The  transfer  is  complete  when  the  end-user  is 
as  satisfied  with  the  compilers'  operation  as  he  was 
before  the  transfer. 

mbe  follovina  chart  and  subsenuent  explanations  help 
depict  areas  of  consideration  invelvinc  transferability . 


Vs. 
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Compiler  n'yr>e  and  structure 

P variety  of  basic  eomoiler  structures  exists.  The 
tvne  of  structure  has  a tremendous  hearing  as  to 
future  adaptation  to  new  taroets. 

Numerous  efforts  have  been  initiated  to  enhance 
eomoiler  transferabil ity,  especially  in  the  area  cf  auto- 
matic compiler  generation  systems.  euch  concepts  as 
meta-compilers,  syntax  table  driven  compilers,  and 
macro  backend  processors  have  had  only  minor  successes 
in  the  adaotation  of  a compiler  to  a new  tarcet  machine. 

'’’hose  that  are  successful,  in  terms  of  inexpensive 
transfer  cost,  have  almost  always  proven  too  costly 
in  other  areas,  (i.e.  noor  code  generation,  extremely 
long  compilation  time) . 


A less  popular  method  involves  compilers  which  generate 
interpretive  code-  With  interpretive  compilers  all 
that  is  usually  required  is  the  implementation  of  a 
nev  set  of  run  time  routines.  The  only  major  drawback 
is  that  proqrams  will  execute  considerably  slower. 

They  will,  however,  compile  faster. 

T's  previously  mentioned,  it  is  strongly  advisable  to 
modularize  the  implementation  of  a compiler  system. 

In  addition,  a compiler's  modules  can  usually  be 
segmented  into  the  following  marts; 

• Program  Control  — Controls  the  overall  flow  of  the 

compiler  and  calls  the  proper  routines 
based  on  the  statements  beina  processed. 

• Parser--'rr?nslates  the  hicher  level  source  into 

an  intermediate  lanauage, 

• Fynression  Pvaluator--Polishes  expressions  so  that 

they  are  more  conducive  to  code  generation. 

• Optimizer — Scrutinizes  the  intermediate  lanauace 

to  minimize  number  of  required  operations. 

• Code  Oenerator--Translates  the  intermediate  source 

to  the  appropriate  instructions  of  the 
tarnet  machine. 
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Tf  a compiler  is  well  structured,  the  only  portion 
which  should  have  to  be  re- implemented  when  transferring 
to  a new  target  is  the  code  nenerator.  Tf  a future 
target  is  a ma}or  consideration , then  the  specifi- 
cation should  require  well  structured  programs. 

• Implementation  Language 

Probably  the  singularly  most  important  factor  in  deter- 
mining the  degree  of  transferability  to  a new  host  is 
the  implementation  language.  The  following  is  a brief 
discussion  of  several  implementation  languages. 

• Assembly  Language 

This  is  by  far  the  least  transferable  (to  a new 
host)  of  any  implementation  language.  Its  major 
advantage  is  that  the  compiler  will  operate  at 
maximum  efficiency  (assuming  good  programming 
technioues) . 

• Macro  Language 

Assuming  the  new  computer(s)  has  a macro  processor 
that  facilitates  the  implementation  of  the  macros 
used  to  implement  the  compiler,  then  this  approach 
nrovides  a very  economical  method  of  moving  to  a 
new  host.  The  disadvantages  involve  the  compiler's 
own  translation  cost  and  the  fact  that  macro  assemblies 
are  usually  very  slow. 
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• Systems  Prooramming  Languaoe 


Often  compilers  are  implemented  in.  a special  higher 
level  language.  Usually  these  lanouages  are  subsets 
of  ALGOL  like  languages.  The  cost  of  transferring 
to  a new  host  is  then  usually  the  cost  of  rewriting 
the  code  generator  of  the  systems  programmina  language. 

• Popular  Higher  Lever  Lanouage 

Since  nearly  all  major  computer  manufacturers  support 
POPTPAN,  COP.OL,  and  possibly  ALGOL  and  PL-1,  the 
use  of  these  lanauages  provides  major  advantages 
if  a new  host  is  of  primary  importance.  In  addition, 

, these  languages  provide  other  benefits  such  as  ease 

of  transfer  of  programmers  already  knowledoeable 
in  the  implementation  lanouage.  '’’he  major  disad- 
1 vantage  is  the  inefficiency  of  the  compiler’s  oper- 

ation,  both  in  terms  of  speed  and  resource  utilization. 


Meta  Compiler 

There  now  exist  numerous  compilers  which  accent  a 
meta-linouistic  definition  of  a lanouage  and  produce 
a compiler  svstem.  The  major  problem  that  exists  in 
this  annroach  is  that  almost  always  the  compiler  is 
very  noor  in  resource  utilization  (space  and  speed) 
as  we 1 1 as  poor  in  terms  of  ouality  of  code  generation. 
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• Modularity 

Modularity  is  a ff'",al  wav  of  dividina  a nroorar  into 
a number  of  subunits.  Fach  subunit  should  have  a v»ell 
defined  ^unction  and  relationship  to  the  rest  oF  the 
oror ra*.  ^are  are  veil  knovn  a^vant aces  in  regularity: 
ne  nri^arv  importance  is  that  those  orccrar  functions 
vhich  ’>’iJ  1 need  the  rest  oroorarrer  attention  upon 
transfer  can  often  be  isolated  and  functionally  iden- 
tified as  distinct  rodules.  mhe  rodules,  if  ornanized 
and  docurented  properly,  can  be  worked  on  with  little 
reference  to,  or  interference  with,  the  rest  of  the 
•arocran  . 

a essential  aspect  of  these  rodules  is  their  isolation 
*ror  the  rest  of  the  rroorar.  rach  section  should  he 
a seouence  of  nrocranrinc  lannuane  staterents  havino 

i 

a veil  rarked  start  and  end.  'T'he  function  of  the 
module  and  its  interface  with  the  rest  of  the  pronram 
should  he  simple  and  veil  docurented.  * rodule 
perform inn  several  closelv  related  functions  rav  have 
several  entry  ’joints,  Povever,  one  ®rtrv  coint  is 

usually  better  practice.  • . 

A corniler  svster  vhere  transferability  is  a rajor  ; 

consideration  should  specify  that  the  rodules  vhich  i 

4 , 

are  machine  dependent  he  isolated  to  as  fev  rodules 


i 


i as  possible.  The  specification  should  also  require 

anpronriate  documentation  that  describes  which  modules 
j need  to  be  chanced. 

t 

i • Parameterization 

? Parameterization  is  a method  by  which  a source  prograr 

may  self-adjust  to  a program,  hardware,  or  system 
modification.  Pome  numeric  or  symbolic  items  in  the 
procrram  may  require,  alteration  if  the  same  function 
is  to  be  performed  in  a new  environment.  These  values 
may  be  written  into  the  code  exolicitly  or  they  may 
; be  parameterized.  In  the  latter  case,  symbolic 

variables  are  set  to  the  anplicable  values  in  an  ini- 
tialization ohase  of  the  assemblv/comoilation . The 
values  chosen  may  be  directly  initialized  by  programmer 
codinq  or  they  may  be  set  up  or  calculate^  by  the 
4 lanouage  processor. 

If  the  value  is  vritten  in  by  the  programmer,  it  should 
be  in  a well  marked  statement,  with  all  such  statements 

f 

collected  in  one  place.  The  documentation  for  each 
value  should  be  exolicit  in  how  and  when  a new  value 
is  to  be  determined  for  the  parameter.  If  the  value 
is  to  be  comouted , the  computation  must  be  checked 
out  for  a range  of  values. 
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Mthouch  a transferred  procram  usually  performs  an 
unaltered  function  on  the  nev?  machine,  parameterization 
may  he  used  even  more  extensively  when  the  prooran 
function  is  altered  durinq  transfer. 

Parameterization  requirements  depend  on  the  details 
of  the  proarams  involved.  Fa.oh  actual  value  in  the 
source  code  »ust  he  considered  for  naremeterization  as 
it  is  being  written.  If  the  value  and  the  represen- 
tation of  that  value  are  independent  of  any  reasonable 
chane0  in  '-aohine  annl  ications , scone,  or  lanrruaqe, 
or  if  the  nrooramming  language  does  not  permit  a 
symbolic  value  in  that  context,  then  narameterization 
does  not  aopjy. 

Tn  oeneral,  over-parameterization  is  rarely  a problem, 
especially  in  the  assembly  or  compilation  process. 
mhus,  the  cost  of  parameterization  is  nontrivial  only 
if  the  logic  of  the  orooram  or  usaqe  of  the  language 
must  be  perverted.  The  value  of  parameterization , on 
the  other  hand,  can  be  consider able . 

• Code  Constraints 

Program  transferability  oan  be  oreatly  enhanced  by 
avoidino  code  that  is  difficult  to  transfer.  binding 
ar.d  using  alternative  rode,  however,  doe*;  involve 
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additional  pronramminq  costs  which  must  be  measured 
against  the  benefits  obtained. 

for  higher  level  languages,  the  primary  code  constraints 
of  concern  involve  the  avoidance  of  language  features 
which  are  apt  to  be  missing  or  altered,  or  which  will 
give  different  results  when  compiled  on  the  transfer 
target. 

The  language  features  most  likely  to  be  missing  or 
different  in  other  compilers  are  the  lancruage  extensions 
and  the  expensive  or  little-used  standard  features. 
Unless  a lancruage  was  specifically  extended  to  suit 
an  apnlication,  use  of  extensions  can  be  avoided  with 
only  a limited  loss  of  efficiency.  In  those  cases 
where  the  standard  languaoe  is  inadequate,  the  unusual 
usaces  should  be  isolated  in  modules  for  recode. 

Aside  from  subsets  and  extensions,  two  things  in  general 
make  code  difficult  to  transfer  - techniques  that  bind 
to  a particular  representation  of  data  structures  and 
instructions,  and  those  that  bind  to  a particular 
sequence  of  operations.  a bindino  technique,  then, 
is  any  usage  that  takes  advantage  of,  or  is  cognizant 
of  its  own  implementation.  V’hen  any  portion  of  any 
instruction  is  used  as  an  operand,  or  when  any  address 
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is  used  which  is  not  completely  symbolic,  a binding 
technique  is  being  used.  Program  code  may  be  cognizant 
of  operation  sequences  because  they  define  a function 
which  must  be  reproduced  when  the  procrram  is  transferred. 

Program  code  which  modifies  itself  has  proven  to  be 
bad  practice  for  reasons  of  maintenance  difficulty, 
error  proneness,  and  non-re-entrant  properties.  Recent 
machines  and  languages  have  taken  steps  to  render  self- 
modifying code  both  unnecessary  (e.g.  execute  instructions) 
and  difficult  or  impossible  (e.g.  write  protect).  Higher 
level  language  code  does  not  directly  allow  dependencies 
upon  instruction  representation. 

Generally,  unless  the  machine  deficient  in  indexing 
and  other  dynamic  address  functions,  representation- 
deoendent  code  may  be  easily  avoided.  Furthermore, 
resource  conservation  realized  through  use  of  this 
type  of  code  usually  amounts  to  only  an  insignificant 
percentage . 

For  any  particular  machine,  external  data  representations 
correspond  to  predictable  internal  storage  bit  patterns. 

It  is  seldom  the  case  that  those  representations  will 
be  equivalent  over  a variety  of  different  machines. 

If  the  external  representation  used  does  not  correspond 
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to  the  function  of  the  item,  the  internal  representation 
will  become  inappropriate  upon  transfer.  An  example 
of  this  type  of  code  is  character  identification  by 
comparison  with  small  decimal  integers. 

Similarly,  packing  several  data  items  in  a word  will 
bind  the  code  with  respect  to  word  size.  A data 
item  may  he  split  by  a word  boundary  upon  transfer, 
for  example,  3 items  of  6 bits  each  do  not  repack  well 
into  a If  bit  word. 

Operation  sequence  and  data  representation  constraints 
can  also  be  combined  in  ways  which  may  seem  of  great 
value  but  which  definitely  hinder  transferability. 

A program  may  be  dependent  upon  aspects  of  system 
configuration  in  ways  that  make  it  infeasible  to 
transfer  the  prooram  to  a system  in  which  those 
aspects  differ  significantly. 

Those  system  attributes  which  become  severe  constraints 
are  usually  either  system  resources  which  are  heavily 
used  or  devices  which  provide  facilities  not  quali- 
tatively present  on  the  new  system. 

Primary  storage  is  likely  to  be  the  constraint  most 
often  felt.  Jf  a compiler  is  written  for  a machine 
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with  a larqe  amount  of  core  storage,  it  pay  be  infea- 
sible to  wove  to  a machine  with  less  storage  unless 
the  program  was  initially  written  with  this  in  mind. 
Similarly,  compilers  often  do  not  adjust  well  to  an 
overlay/nonoverlay  transition  since  basic  algorithms 
may  differ  (overlay  Drocessing  often  renuires  a file 
pass  for  each  phase,  where  this  would  be  unnecessary 
with  adeouate  primary  storaqe) . On  the  other  hand, 
large  primary  storage  may  have  been  crucial  to 
efficient  operation  of  the  nrograr,  and  it  would  he 
wasteful  not  to  use  it. 

One  approach  to  this  problem,  then,  is  to  consider 
(and  document)  primary  storage  size  as  a system 
constraint  precludinq  code  and  nerhaps  desian  for 
transfer  to  a machine  with  less  storage. 

similar  considerations  apoly  to  random  versus 
sequential  access  secondary  storaoe  devices. 

In  the  area  of  inout/output , efforts  must  be  directed 
toward  avoidance  of  explicit  references  to  physical 
devices  which  can  permanently  bind  a proqran  to  a 
particular  conf iauration . Programmers  should  design 
and  code  with  logical  entities  such  as  the  system 
input  device  (rather  than  the  card  reader)  or  the 
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object  output  file  (rather  than  the  tape  punch) . 

Physical  devices  and  their  associated  characteristics 
(such  as  record  length)  must  be  parameterized  and 
isolated  from  the  main  body  of  the  program  as  much 
as  possible. 

• Emulator/Simulator 

The  development  of  an  emulator  or  simulator  that  operates 
on  one  host  and  emulates  another  is  another  means  of 
transfering  a compiler  to  a new  host.  This  method 
is  almost  always  an  unlikely  alternative  considering 
the  major  disadvantage  of  excessive  resource  utili- 
zation on  the  new  host. 
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1.6  Environment 

The  operating  environment  or  computer  system  must  be 
well  defined  before  compiler  development  begins. 

Future  systems  are  discussed  in  Section  l.S.  The 
initial  environmental  specification  should  be  directed 
toward  two  operational  levels  - minimum  and  capacity. 

The  minimal  configuration  for  processing  "average" 
programs  one  at  a time  may  be  a milestone  in  development 
and  payment.  The  capacity  consideration  is  the  largest 
or  most  (multi-programming)  compilation (s)  which  are 
expected  in  the  application  program  developmental  cycle. 

This  information  affects  several  areas: 

e Hardware  acguisition  and  selection 
e Compiler  implementation 
e Compiler  transfer 
e User  base  and  profile 
e Choice  of  operating  system 

e Programming  capacity-size  of  source  programs 

A procuring  agency  which  over  estimates  available  core 
storage,  for  example,  may  severly  limit  the  size  of 
source  programs  and  the  number  of  users  who  may  run 
simultaneously. 
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1.7  System  Interface 
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'T’he  ease  with  which  a user  can  access  a compiler  file, 
link  compiler  object  modules,  and  re-run  compilations 
is  of  paramount  importance  in  the  specification  of  a 
compiler  system.  Mo  tool,  no  matter  how  good,  is 
really  useful  unless  it  can  be  satisfactorily  applied 
within  the  system. 

Although  some  aspects  of  this  problem  seem  self  evident, 
they  should  not  be  left  to  the  imagination  of  the  vendor, 
mhe  specification  should  clear]'/  state  the  desired 
system  interfaces.  mhe  following  chart  and  subsequent 
descriptions  will  provide  representative  specifications 
for  system  interface. 


Operating  System  Interface 

Job  Control  Language  requirements 
Interface  with  System  Text  Editor 

object  Lancuane _ 

Interface  with  other  Languages 

Subroutine  Linkages 

Resource  Tsace 

COMPILE?  SPECIFICATION  - SYSTEM  INTFPFA.CE 
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• operating  System  Interface 

T'  compiler  interfaces  with  the  operating  system  for 
the  following  major  tasks: 


• mo  he  criven  control  to  execute 

• To  attain  its  share  of  resources 

• To  receive  user  input  files 

• mo  transmit  user  output  files. 

Tt  is  advisable  that  a comoiler's  specification  includes 
definitions  of  operation  svstem  tasks  to  be  used  and 
weans  by  which  it  is  to  perform  the  above  tasks.  It  is 
also  advantacreous  for  the  interface  to  the  operating 
svstem  to  be  centrally  located  in  the  minimal  number 
of  modules.  ror  example,  it  is  quite  possible  to  have 
*our  ’-odules  for  each  of  the  four  functions  above, 
.^rouc'cnts  to  the  modules  can  ho  used  for  determining 
the  necessary  tasks  to  be  performed,  as  shown  below 

• Subroutine  Marne:  Control 

Function:  Fntry  point  of  compiler,  riso  includes 

exit  to  operating  system  and  any 
necessary  interface  for  attaining  or 
presetting  system  information  (e.e. 
obtaining  date  of  compilation,  etc.). 
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• Subroutine  Mane  Pesources: 

Function:  Obtain  internal  storage  requirements 

for  compiler. 

Inputs:  Amount  of  space  required. 

• Subroutine  Peceive/Transmit 

Function:  Obtain/Output  a record  from/to 

a user  file. 

Inputs:  File  name  or  number,  buffer  to 

receive/transmit  record,  size  of 
record,  mode  (NSCIT,  EBCDIC,  Pinary, 
etc.),  Operation  (Normal,  rewind , 
end  of  file,  etc.) 

In  order  to  insure  the  desired  operating  system  inter- 
face, the  compiler  specification  should  contain  detailed 
descriptions  of  the  above  interfaces. 

• JCL  Requirements 

Nearly  all  modern  operating  systems  require  a control 
language  specification  (job  control)  prior  to  job 
submission.  The  "JCT."  describes  the  programs  to  be 
executed  and  the  environment  for  execution.  It  is 
crucial  that  minimal  job  control  and  knowledge  of 
operating  system  idiosyncracies  be  reguired  for  a 
compilation . 
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A user  should  not  have  to  become  a JCL  expert  to  have 
his  program  translated,  Psually,  operating  systems  will 
allow  the  invocation  of  JCL  from  procedure  libraries, 
thereby  allowing  a user  the  capability  of  minimizing 
his  JCL  requirements.  Tt  is  reasonable  to  include  in 
the  specif ication  that  JCL  for  all  typical  compilations/ 
executions  be  provided  to  simplify  the  user’s  interface 
with  the  compiler. 

• Interface  with  the  Pvstem  Text  Fditor 

IF  the  compiler  is  part  of  a system  which  contains 
a text  editor,  then  the  compiler  source  input  files 
should  be  in  a format  that  can  be  used  by  the  text 
editors,  often  compilers  will  encode  the  source, 
thereby  renderinc  any  system  text  editors  useless. 

• Object  Language 

A language  processor  translates  a source  program  to 
a form  that  is  readily  loadable  into  a comruter.  This 
fori-’  is  called  an  object  language.  *n  existing  system 
will  usually  contain  loaders  and  linhaor  editors  that 
process  the  object  language.  "he  c omniler  specifi- 
cation should  stipulate  that  the  object  language  be 
compatible  with  the  existing  system's  object  language. 


am 
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• Interface  with  Other  Languages 


If  it  is  deemed  desirable  to  inplement  a system  using 
more  than  one  language,  it  should  be  rade  part  of  the 
specif ication . Compatibility  among  data  structures, 
object  languages,  and  file  structures  will  enable  the 
use  of  additional  system  language  processors.  This 
is  especially  important  with  respect  to  existing 
assemblers . 

• Subroutine  linkages 

Usually  a system  will  contain  a standard  procedure 
for  calling  a subroutine.  This  will  include  both  the 
activation  of  the  subroutine  and  the  passing  of 
arouments.  If  such  a convention  exists,  it  is  strongly 
advisable  that  the  sneci f ication  include  this  as  a 
requirement.  ts  no  convention  exists  (or  if  the 
standard  convention  is  deemed  not  worthy  of  consider- 
ation) , then  the  compiler  soecif ication  should  reouire 
a consistent  method  be  used  throughout  the  compiler. 

• resource  f’sage 

resource  usage  can  be  considered  in  two  basic  environ- 
ments, compile  time  and  execution  time.  There  is 
often  a correlation  between  expensive  resource 
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utilization  Purina  compilation  of  a source  program 
an d economical  execution  of  the  source  program,  or 
vice  versa.  Modern  software  technology  coupled  with 
usually  available  syster  softv/are  facilities  (e.g. 
overlay  loaders,  selective  loading  of  object  modules) 
enables  compiler  systems  to  minimize  their  resource 
requirements . 

Usually  there  is  no  major  benefit  in  having  the 
entire  compiler  core  resident  during  corpilation. 

Source  compression  technology,  with  efficient  usage 
of  data  and  file  structures,  allows  large  compiler 
systems  to  operate  efficiently  without  usurping  vast 
resources  trom  the  system.  If  left  unspecified,  the 
procuring  anency  mav  find  their  compiler  using  enormous 
amounts  of  memory  and  resources,  "hereby  the  compiler 
system  becomes  virtually  a stand  alone  operation. 


1.8  bser  frofile 


The  number  and  types  of  users  of  a compiler  can  have 
large  effects  on  its  efficiency  and  Derformance  ratine, 
("“omnilers  designed  to  meet  a wide  ran oe  of  source 
program  sizes,  for  example,  m?y  not  produce  the  most 
efficient  code  or  mav  require  extensive  link-loader 
procession.  p one-nass  increnental  system  ray  corpile 
quickly  hut  execute  slowly . ? multi-pass , optimized, 

compiler  ray  corpile  slovlv  and  execute  rapidly,  etc. 

ci"'ilarlv,  a comniler  which  is  hinhly  optimized  and 
capable  of  handlina  larne  source  files  is  not  efficient 
for  a tutorial  situation  requirino  fast  response  and 
many  users. 

mhe  procurina  aqency  should  identify ? 

• the  prospective  set  of  users 

• procrrams 

• experience  levels 

• percentage  o*  tutorial  or  "fun"  compilations 
(as  in  a university) 

• life  expectancy  or  "production"  nercentaoes 

• real-time  requirements 

• number  of  simultaneous  users 

• desired  resnonse  times 
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The  user  profile  specified  should  provide  the  basis 
for  acceptance  tests.  Those  tests  which  most  closelv 
resemble  the  user  profile  should  corpile  the  most 
efficiently. 


1 . 9 Documentation 
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Documentation  is  vital  to  the  successful  use  and  main- 
tenance of  any  compiler  system.  A compiler  system  with- 
out adequate  documentation  is  worthless.  A compiler 
system's  documentation  can  be  divided  into  two  parts, 
internal  (maintenance)  and  external  (user-oriented) . 

Any  compiler  specification  should  include  requirements 
for  sufficient  documentation  in  both  areas.  The 
following  chart  and  subsequent  descriptions  will  help 
provide  several  insights  into  the  types  of  documentation 
that  can  be  provided. 


User  Manual 

Job  Setup 

Primer 

Training  Material 

Compiler  Limitations/Idiosyncracies 

Diagnostic  Description 

Syntactical  Language  Description 

User  Flow  Charter 

Compiler  Source  Listings 

Flow  Charts/Prosaic  Description/ 
Variable  Descriptions 

System  Generation 

System  Interface 

COMPILER  SPECIFICATION  - DOCUMENTATION 


! 
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• User  Manual 
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Every  compiler  specification  should  require  a user 
manual.  The  users'  manual  should  describe  the  usage 
of  all  compiler  features  as  well  as  examples  illus**  . 
trating  their  use. 

Job  Setup  Description 

Often  this  can  appear  as  part  of  a user  manual  (usually 
an  appendix) . This  describes  how  to  compile  and/or 
execute  programs.  It  should  clearly  specify  each 
step  and  the  entire  range  of  job  submittals. 

Primer 

If  the  language  is  new,  or  if  it  contains  different 
concepts,  or  if  it  is  to  be  used  by  relatively  inex- 
perienced programmers,  it  is  beneficial  to  have  a 
primer  specifically  describing  these  attributes. 

Training  Material 

In  addition  to  primers,  it  is  beneficial  to  develop 
visual  training  aids  and  sample  decks  or  terminal 
inputs  for  a new  compiler  system. 
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• Compiler  Limitation/Xdiosyncracies 

This  item  often  appears  as  an  appendix.  Although 
essential,  it  is  too  often  missing  from  the  available 
compiler  documentation  or  is  scattered  throughout  a 
variety  of  manuals.  Zt  is  vital  that  all  compiler 
limitations/idiosyncracies  be  contained  in  an  easily 
accessible  document. 

e Diagnostic  Description 

> 

All  error  messages  should  be  contained  in  one  con- 
tiguous document  (or  a user  manual  appendix) . The 

» 

diagnostics  should  include  details  of  how  and  why 
each  error  occurs  and,  if  appropriate,  what  action 
is  to  be  taken. 

I 

> e Syntactical  Language  Description 

This  should  be  part  of  the  compiler  specification  and 

* 

also  be  available  to  users.  As  mentioned  previously, 
a meta-linguistic  notation  ' g.  Backus  Nauer  Format) 
along  with  a prosaic  descn  ion  should  be  used  to 
specify  all  possible  language  constructs. 

e User  Flow  Charter 

The  inclusion  of  a program  which  will  automatically 
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generate  flow  charts  for  application  programs  may  be 
beneficial  to  users.  The  costs  of  this  item  must  be 
weighed  against  the  potential  benefits.  Usually  auto- 
mated flow  charts  of  higher  level  languages  provide 
little  more  than  a slightly  better  pictorial  arrange- 
ment of  the  program  flow. 

e Compiler  Source  Listings 

It  is  essential  that  the  compiler  implementors  provide 
' well-commented,  well-structured  source  listings  if  the 

procuring  agency  expects  any  type  of  reasonable  main- 
, tenance  or  understanding  of  the  programs.  All  good 

programming  habits,  as  enumerated  by  recent  articles 
(topics  including  structured  programming , top-down 
1 design,  modularization,  etc.)  are  beneficial  to  the 

> individuals  responsible  for  maintaining  or  modifying 

the  compiler. 

• 

e Flow  Charts/Prosaic  Description/Variable  Description 

* The  value  of  technical  documentation  is  extremely 

difficult  to  measure.  Brief  synopsis  of  the  various 
compiler  elements  along  with  flow  charts  of  complex 
algorithms  are  usually  helpful  to  the  maintenance 
programmer.  It  is  essential  that  a technical  document 
s 
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contain  sufficient  comments  describing  every  variable. 


e System  Generation 

It  is  essential  that  a document  be  provided  that 
illustrates  the  methodology  for  symbolic  modifications 
to  the  compiler  and  then  made  to  be  operational  as 
part  of  a new  system.  The  specifications  should 
always  include  this  as  part  of  the  required  technical 
documentation . 

e System  Interface 

It  is  also  important  that  technical  documentation 
exists  as  to  what  system  facilities  are  used,  how 
they  are  used,  and  where  they  are  invoiced.  Often 
a new  system  facility  will  replace  an  existing 
facility.  Unless  documentation  is  provided,  the 
maintenance/modification  to  support  such  changes 
becomes  extremely  complex  and  costly. 
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The  compiler  specification  RFP  and  vendor  supplied 
proposals  should  both  contain  an  implementation  schedule 
with  provisions  for  milestone  payments.  The  actual 

schedule  time  requirements  vary  tremendously  with  language,  I 

compiler  efficiency,  implementation  strategy  and  hardware 
constraints.  Large  scale  compilers  such  as  PL/1  may 

require  more  than  one  linear  year  to  initial  completion.  j 

Less  efficient  implementations  of  FORTRAN  and  BASIC  may  j 

require  only  a few  man  months.  The  actual  schedule  will 
be  a judgement  based  on  choice  of  vendor,  language  and 
options.  Typical  payment/acceptance  milestones  in 
development  can  be  identified,  however. 


• Compiler  design  - detailed  written  descriptions  of 
compiler  modules,  intermediate  languages,  object 
languages,  parsing  and  translation  algorithms  to 

be  used.  This  is  the  basis  for  compiler  documentation 
and  should  be  done  first . 

• Parsing  and  Translation  - a demonstration  of 
successful  generation  of  intermediate  language  from 
a test  source  prooram. 

e Code  generation  - demonstration  of  programs  to 
convert  intermediate  languages  to  relocatable  or 
loadable  object  forms. 
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• Initial  Configuration  - a first  stage  compiler 
capable  of  processing  simple  language  forma  to  un- 
optimized link  or  loadable  object. 

• Optimizer  - A demonstration  of  compiled  code  which 
has  been  optimized  and  executed  successfully. 

• Self-compilation  - if  applicable — complete  com- 
pilation and  optimization  of  the  compiler  programs 
and  subsequent  use  of  the  compiled  object  to  run 
additional  tests. 

e Performance  Tests  - compiler  performance  acceptance 
tests. 

• Documentation  Package 

e Training 

• Agency  Trial  Period  - before  final  payments,  the 
user  organizations  should  make  exhausted  use  of  the 
compiler  and  critique  its  performance. 

• Compiler  Modification  - as  a result  of  user  tests, 
enhancements  and  alterations  may  be  required  for 
maximum  use  and  efficiency. 

e Maintenance  Period  - final  developmental  payment 
should  be  made  before  the  beginning  of  the 
maintenance  period.  Maintenance  may  be  defined 
as  correction  of  bugs  not  found  in  previous  testing. 
Changes  to  the  specifications  and  enhancements  are 
not  maintenance  items. 
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A vital  part  of  any  compiler  specification  is  the 

- | 

acceptance  test.  Usually  the  compiler  implementor  will 
generate  a set  of  test  cases  during  the  development  phase 
and  the  procuring  agency  will  nod  their  tacit  approval 
as  acceptance  tests.  Far  too  often  these  tests  are  later 
found  to  be  incomplete  and  subsequent  usages  of  the 
compiler  cause  the  discovery  of  numerous  problems. 

j 

j Several  existing  languages  have  a set  of  tools  that  aid 

in  the  validation  of  a compiler.  The  quality  and 
comprehensiveness  of  the  acceptance  tests  are  extremely 

* important  in  the  initial  acceptance  of  a compiler. 

with  the  increasing  complexity  of  the  new  compiler  systems, 
it  is  necessary  that  acceptance  tests  proceed  beyond  a 
mere  superficial  state  of  initial  debugging.  The  desire 
to  "just  get  it  working"  has  prevailed  in  so  many  compiler 
development  efforts,  that  the  initially  delivered  product 
has  often  proven  to  be  a future  pandora's  box. 

The  compiler  specification  should  include  statements 
specifying  the  use  of  automatic  program  testing  tools, 
if  available.  If  not,  then  the  following  chart  lists  some 
of  the  tests  which  should  be  provided.  It  is  usually 
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advisable  that  the  acceptance  tests  be  developed  by  the 
procuring  agency  shortly  after  the  design  phase  of  the 
compiler. 

A great  need  exists  for  structured  methods  in  the  testing 
of  a compiler  system.  It  is  impossible  to  test  all 
possible  paths  in  a complex  compiler  system.  For  example, 
assume  a compiler  system  has  2^4  different  paths  (a  very 
small  number  with  respect  to  a fairly  complex  compiler 
system) . Using  a computer  with  an  internal  speed  of  1 
microsecond,  it  might  seem  reasonable  to  verify  all 
possible  paths,  while  in  actuality,  approximately  1000 
years  of  computer  time  would  be  required. 

The  following  chart  lists  those  items  which  should  be 
included  as  part  of  the  acceptance  tests.  The  development 
of  test  cases  for  each  of  these  items  should  be  made  part 
of  any  compiler  specification  in  order  to  assure  a 
reasonable  degree  of  reliability  for  a new  compiler  system. 
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Syntax  Teat 

Statement  Test 

Diagnostic  Test 

Accuracy  Tests 

Execution  Test 

Limit  Tests 

Special  Feature  Tests 
Resource  Test 

COMPILER  SPECIFICATION— ACCEPTANCE  TESTS 

• Syntax  Test 

A set  of  test  modules  that  verifies  the  compiler's  grammar 
and  handles  all  legal  syntax  structures. 

• Statement  Test 

A set  of  test  cases  that 'verifies  the  proper  translation 
for  each  possible  statement,  and  their  use  in  conjunction 
with  other  statements. 

• Diagnostic 

A set  of  test  cases  which  generates  every  known  compiler 
error..  If  an  error  can  be  created  for  a variety  of 
circumstances , then  each  possible  cause  should  be  made  a 
part  of  the  test. 


N 

i 


1-69 


Accuracy  Test 


A set  of  test  cases  to  verify  the  accuracy  of  compiler 
specified  mathematical  operations,  functions,  etc. 

This  includes  tests  that  convert  from  one  numeric  mode 
to  another  (eg.  integer  to  floating  to  integer,  etc.). 

e Execution  Test 

A set  of  test  cases  that  verify  that  the  compiler  system 
translates  all  possible  statements  to  executable  code. 

e Limit  Test 

It  is  essential  that  a set  of  test  cases  be  developed 
which  check  all  compiler  limits.  For  example,  a test 
case  that  includes  numerous  identifiers,  extremely  long 
symbol  names,  maximum  parentheses,  maximum  loop  nesting, 
maximum  continuation,  etc.  Often  these  test  cases  are 
ignored  and  prove  to  be  future  bottlenecks. 

e Special  Features  Test 

A set  of  test  cases  to  validate  the  proper  operation  of 
all  special  features  should  be  required  and  so  stated  in 
the  specification. 
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• Resource  Usage 

A "typical  application  program"  should  be  developed  to 
measure  resource  usage.  This  includes  both  compile  and 
execution  time  resources.  Often  this  test  case  will  have 
to  include  special  hooks  into  the  compiler  so  that  statis- 
tics (time,  space,  1/0  accesses)  may  be  properly  recorded. 
This  test  case  can  be  used  to  verify  that  the  maximum 
specification  requirements  (resource  usage)  are  not 
exceeded. 
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1.12  Maintenance  and  Support 

The  acquisition  of  a compiler  system  should  include  plans 
for  its  continual  maintenance  and  support.  Normally  a 
vendor  will  maintain  a software  product  at  no  cost  to  the 
procuring  agency  for  a jointly  specified  time  frame  after 
product  acceptance.  As  mentioned  previously,  even  if  the 
acceptance  test  cases  are  implemented  with  extreme  care, 
it  is  impossible  to  verify  all  paths  of  logic  within  a 
complex  compiler  system.  Therefore,  the  specification 
should  include  plans  for  product  maintenance  throughout 
the  expected  life  of  the  compiler  system. 

Numerous  programmers  have  used  an  existing  "field  tested" 
compiler  only  to  encounter  problems  after  five  to  ten  years 
of  compiler  usage.  The  complexity  of  a compiler  system, 
and  its  critical  importance  as  a software  tool  warrants 
future  maintenance  requirements  be  established  at  the 
time  of  specification. 

As  new  problems  are  encountered  in  a compiler,  it  is 
advisable  to  modify  the  acceptance  test  to  include  these 
problems.  This  will  tend  to  insure  error  free  future 
versions. 
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The  utility  of  a compiler  system  is  determined,  in  part, 
by  the  ease  with  which  it  may  be  used,  corrected,  modified, 
and  updated.  The  following  descriptions  of  the  items  in 
the  chart  below  enumerate  the  requirements  for  effective 
maintenance  of  a compiler  system. 


Technical  Documentation 

Debug  Tools 

Skilled  Programmers 
Warranty  Contract 


COMPILER  SPECIFICATION  - MAINTENANCE 
• Technical  Documentation 

It  is  vital  to  any  maintenance  effort  that  efficient 
technical  documentation  exist.  Since  the  source  program 
for  the  compiler  is  the  only  guaranteed  actual  program 
logic,  a well  structured  source  is  the  best  assurance  of 
future  maintenance. 

Small  modules,  meaningful  variable  names,  and  sufficient 
commentary  to  explain  algorithms  and  routine  functions  are 
a prerequisite  to  a maintainable  system. 
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• Debug  Tools 


when  problems  arise^ it  is  almost  imperative  that  debug 
aids  exist  to  help  isolate  and  eventually  correct  the 
problem. 

e Skilled  Programmers 

Usually  the  implementors  of  compilers  are  well  versed  in 
the  technical  requirement  of  developing  language  processing 
systems.  Often  junior  level  people  are  hired  to  maintain 
a system.  The  specification  writer  should  consider  the 
level  of  maintenance  required  when  deciding  on  or  accepting 
a set  of  individuals  to  maintain  the  compiler. 

e Warranty  Contract 

It  is  almost  always  advisable  to  have  the  company  personnel 
that  implemented  the  compiler  be  responsible  for  its 
warranty.  If  the  warranty  is  to  exist  over  an  extended 
period  of  years,  as  if  often  the  case,  the  specification 
should  attempt  to  have  more  than  one  individual  cognizant 
of  the  internal  workings  of  the  compiler  system.  In 
Addition,  the  agency  which  has  the  maintenance  respon- 
sibility should  be  held  responsible  for  the  transfer  of 
knowledge  if  the  individuals  are  transferred  elsewhere.  j 
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The  specification  should  state  the  response  tine  for  the 
correction  of  problens.  Zn  addition,  a standard  method 
of  reporting  problems  should  be  adopted.  Periodic  status 
reports  should  be  made  available  to  users  whenever  new 
problems  arise  or  are  corrected. 
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Part  2 COMPILER  ACCEPTANCE 

The  development  of  an  objective  decision-making  process 
when  accepting  a compiler  is  extremely  important  in 
insuring  a successful  compiler  system.  Part  1 provided  a 
means  of  identifying  the  features  and  facilities  available 
for  a compiler  system  and  for  their  reasonable  specification 
to  the  vending  organization.  The  specification  charts 
developed  in  Part  1 also  provide  a meaningful  basis  for 
development  of  acceptance  criteria.  In  reality,  the 
weighting  factors  or  scores  introduced  in  this  section  are 
only  meaningful  in  terms  of  the  importance  or  desireability 
of  items  specified  in  Part  1. 

The  approach  taken  in  this  guideline  is  to  change  numerous 
qualitative  evaluations  into  quantitative  scores  with  i 

weights  provided  for  each  category.  A summation  of  the  j 

evaluation  provides  a compiler  score.  The  score  is  then  j 

i 

used  as  an  index  into  an  acceptability  chart.  Since  this  * 

j 

guidebook  was  not  developed  with  any  particular  language  „ 

or  user  group  in  mind,  the  relative  weighting  scores  j 

J 

assigned  are  based  on  a hypothetical  compiler  system. 

The  representative  acceptability  chart  below  is  based  j 

on  a perfect  score  of  1000  points.  j 

* 

i 
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COMPILER  ACCEPTANCE  CHART 


Score 

Evaluation 

950-1000 

Excellent 

850-949 

■ ■■■  ■ 

750-849 

Temporarily 

Acceptable 

0-749 

Completely 

Unacceptable 

It  seems  advisable  that  future  compiler  system  contracts 
include,  as  part  of  the  payment,  an  amount  based  on  the 
acceptability  score.  This  additional  financial  remune- 
ration could  provide  the  incentive  needed  to  turn  accep- 
table and  good  compilers  into  excellent  compiler  systems. 

In  the  following  sample  compiler  acceptance  matrix,  the 
acceptance  of  a compiler  is  divided  into  ten  parts.  Each 
part  is  given  an  empirically  derived  total  point  potential. 

The  values  specified  below  should  be  modified  to  the 
particular  requirements  of  the  compiler  system  being 
developed.  The  matrix  shows  each  of  the  major  categories, 
potential  and  eventual  actual  scores.  If  certain  categories 
are  not  applicable  to  the  compiler  systems  acceptability, 
then  the  total  Doint  potential  of  the  remaining  categories 
should  be  modified  accordingly. 


2.1  Accuracy  and  Reliability 


The  speed  of  compilation,  minimization  of  system  resources 
and  superlative  user  options  are  of  little  value  unless 
the  compiler  is  able  to  generate  valid  object  code  for 
higher  level  source  statements.  The  attributes  of 
accuracy  and  reliability  are  best  judged  by  acceptance 
test  program  runs  that  are  compared  with  expected  results. 

There  are  several  attributes  of  a more  general  nature 
which  can  be  checked  for  in  a compiler  that  affect  the 
overall  system's  accuracy  and  reliability.  The  following 
matrix  depicts  the  items  used  to  measure  a compiler’s 
accuracy  and  reliability.  This  matrix  is  organized  by 
the  features  and  structure  of  languages  and  compilers. 


COMPILER  ACCEPTANCE  - ACCURACY  AND  RELIABILITY 


• Compiler  Internal  Structure 


A compiler  can  be  portrayed  as  comprising  two  major 
processing  functions. 


These  compiler  elements  likewise  reflect  the  five 
basic  factors  which  effect  compiler  reliability: 
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These  compiler  functions  directly  relate  to  hardware, 
operating  system  facilities,  language  and  the  imple- 
mentation techniques  employed. 


Although  this  representation  is  somewhat  simplified 
or  general  in  nature,  it  does  provide  insight  into  the 
inherent  opportunities  for  modularization.  Modulari- 
zation is  the  single  most  important  factor  in  predictive 

j 

reliability  and  ease  of  maintenance. 

i 

y 
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A compiler  implemented  using  structured  programming 
techniques  is  also  a candidate  for  high  reliability 
scores. 


y 

In  general , then,  if  a particular  set  of  acceptance  test 

F 

I cases  are  successfully  executed  and  the  compiler  is 

i ■ 

both  modular  and  structurally  programmed,  there  is  a 
high  probability  that  similar  programs  will  be  valid. 


\ Structured  programming  and  modularization  and  both 

somewhat  subjective  concepts  to  measure.  Because  of 
this,  a visual  inspection  of  listings  and  internal 
structure  flow  charts  may  be  necessary.  Some  items 
of  interest  in  such  an  inspection  include: 


I 


e parameterization 
e meaningful  source  commenting 
e open-endedness 

e size  of  sub-programs  and  dependence  on  complex 
scope  relationships 

e simplicity  of  linkages  and  arguments  passed 
between  modules 

e indirect  addressing  and  deeply  nested  pointer 
schemes 

e degree  of  isolation  of  target  dependent  modules 
• re-entrancy 
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• recursion 

• host  dependent  coding 

• Syntax  and  Semantics  Analyzers 

Basic  components  of  any  compiler  are  the  syntax  and 
semantics  analyzers,  sometimes  called  the  parsing 
algorithm.  The  SOFTECH  report  and  other  recognized 
studies  have  indicated  that  the  choice  of  parsing 
algorithms  is  not  as  crucial  to  reliability  as  is  its 
implementation  technique.  Items  to  include  in  tests 
of  this  area  are: 

9 scanning  - number  of  blanks,  multiple  operators, 
deeply  nested  syntax 

9 spelling  - use  of  similar  but  not  equal  names 
such  as  abbreviations,  extensions, 
reversed  letters 

e searching  - speed  of  search  as  a function  of 
label  size,  number  of  labels 

• recovery  procedures  - skipping  erroneous  constructs 

pinpointing  errors 

e addressing  errors  - out  of  range  or  undefined 
labels  flagged  before  "assembly" 

e mode  definitions  - default  variable  classifications 

• uninitialized  variables 


• sealing  and  conversion  anomalies  - infinite  and 
0 results  predictable  at  compile  time 


r . 


« 


■ 
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bit  packing 
nesting  levels 

constant  conversion  - artificial  or  host  induced 
magnitude  and  accuracy  constraints 


e Assignment  Statements 

f 

Assignment  statements  are  given  a high  relative  weighting 
in  determining  accuracy  and  reliability.  Although  the 
definition  of  assignment  infers  simply  computing  and 
storing  a value,  almost  all  of  the  compilers' functions 
are  tested: 

e parsing 

e evaluation  of  expressions 
e searching 

• data  conversion 
e function  linkage 

e variable  initialization 
e fetch  and  store 
e optimization 

e parallel,  serial,  array  addressing 
e code  generation 

• cross-reference  and  user  aids 


i 


i 

< 

i 
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In  particular,  in  languages  allowing  multiple  assignment, 
a simple  test  may  detect  complex  errors.  For  example: 

I * signed  item 

J • array  of  floating  point  items 


- <I+1)/J(I) 


may  be  defined  as: 


<I0+l)/JUo>-»  *1 
CX0+l)/J(X0)->  Jdo> 


or  as: 


(X0+1)/J(lo)-^  II 
dl+l)/Jdl)-#J(Il) 


or  other  possibilities  dependent  on  language  definition, 
and  compiler  analization  techniques,  and  data  conversion 
algorithms . 

Sample  assignment  statements  can  and  should  be  easily 
hand  checked  for  expected  results. 


e Declarative  Statements 


1 


Declarative  statements  exercise  parsing,  searching, 
allocation,  initialisation,  subroutine  linkage,  addressing 
structure  and  routines.  Items  which  can  be  best  checked 
include : 

e declarative  statement  syntax 
e mode,  value,  or  array  structure  assumptions 
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• levels  of  subscripting- index in? 
e parallel  structure 
e packing 
e data  conversion 

e interfaces  to  assembly/higher  languages 
e visability  of  variable  placements 
e overlay  and  equivalence 
e continuation  statements 
e statement  sizes 

e addressing  range  and  virtual  locations 
Subroutine  Statements 

Subroutine  or  subprogram  statements  are  particularly 
important  for  checking  scope,  modularity  and  addressing. 

Subprograms  should  be  compiled  separately  and  also  \ 

in-line  to  verify  language  rules. 

e Addressing  techniques  may  become  cumbersome  or 
inefficient  in  separately  compiled  structures, 
e Identically  named  variables  may  be  erroneously 
addressed  or  set  in  nested  subroutines, 
e High  usage  core,  such  as  directly  addressed 
pages  in  base  register  machines,  may  be  easily 
over-loaded  as  the  number  of  routines  and/or 
arguments  increases. 
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Linkages  or  register  contents  should  be  maintained. 
Re-entrances  or  recursion  may  not  exist. 

Artificial  calling  linkages  or  nesting  limits 
may  exist. 

Registers  may  be  unused  or  unavailable  causing 
inefficient  code. 


\ 


* 


e 


Control  Statements 


These  statements  control  program  flow  and  sequence  of 
execution.  Tests  in  this  area  should  include: 
e loop  control  and  exiting 
e subroutine  calls  and  returns 
e subroutine  control  arguments 
e computed  transfer  ranges , defaults,  error 
detection  and  data  conversion 
e user  warnings 
e parallel  and  embedded  scope 
e begin-end  structures 
e conditionals:  ZF,  THEN,  ELSE,  WHILE 

e addressing  range  and  technique 
e instruction  set  and  condition  code  usage 

e Input/Output 

There  are  several  major  areas  of  reliability  which  are  of 
concern  when  verifying  input/output  statement  compilations. 
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These  include: 


l 
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\ 
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• Tinting  dependencies  - computations  may  be  improperly 
made  if  instruction  sequence  execution  proceeds 
during  input/output.  Similarly,  execution  times 
may  increase  if  wait  states  occur  unnecessarily. 

Data  may  be  lost  or  filled  during  hardware  mal- 
functions. 

• Machine  independence  - the  modularization  of  I/O 
routines,  pointers  and  run-time  package  linkages 
should  be  verified. 

e Artificial  coding  restraints  - source  language  usage 
should  not  be  tied  to  record  sizes  or  block  control 
flags  unless  specified  in  the  language, 
e Parity  and  data  checks  should  be  verified  to  insure 
integrity  of  the  source  program  computations, 
e Format  statements  and  similar  input/output 

structures  should  be  tested  for  data  conversion, 
packing  and  error  checking  capabilities. 

• Limits 

Internal  compiler  structure  limitations  can  be  tested 
via  several  of  the  statement  types  previously  listed. 

Of  particular  and  common  interest  are  ranges  of  values  for: 
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• compiled  program  array  dimensions  and  execution 
time  index  values  which  are  out  of  range  - 
default  conditions , error  recovery , coetpile 
time  checks , maximum  values 
e label  sizes 
e character  constant  sizes 
e record  sizes  for  I/O 

e array  dimensionality  maximums  and  the  relationship 
of  dimensionality  to  object  code  efficiency 
e FOR- DO  loop  nesting  limitations 
e FOR- DO  loop  scope  limitations 
e nesting  of  array  indices 
e nesting  of  subprogram  function  calls 
e nesting  of  IF  THEN  ELSE  structures 
e number  of  subprograms 

e number  of  continuation  lines  and  characters 
in  a statement 

e maximum  program  (loadable) 

e maximum  number  of  items,  tables,  arrays,  symbols 
e dynamic  table  re-allocation  (when  a limit  is  reached) 
e operator/operand  sequences 
e nested  parentheses 
e COMMON  or  COMPOOL  sizes 
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• Documentation  and  Diagnostics 


* 
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Accuracy  and  reliability  are  also  important  in  system 
and  user  documentation.  The  results  of  previous  language 
constructs  and  compiler  implementation  tests  should  have 
been  predicted  in  the  vendor  documentation. 

This  is  particularly  true  of  limit  tests,  data  conversion 
anomalies  and  input/output  characteristics.  If  vendor 
documentation  does  not  contain  a high  percentage  of 
correctly  predicted  limits  and  anomalies,  then  it  is 
probable  that  the  vendor  has  not  performed  adequate 
reliability  and  accuracy  tests. 

Similarly,  re-hosting  or  re- targeting  documents  should 
be  randomly  checked  for  accuracy.  If  a routine  is 
documented  as  having  a particular  function,  it  should 
be  checked  by  visual  inspection  of  the  code  and  by 
trace  and  dump  techniques. 

All  error  messages  should  be  purposely  generated  by  test 
and  compared  to  user  documentation.  Again,  if  the 
documents  do  not  reflect  the  actual  results,  some 
feeling  for  compiler  reliability  may  be  surmised. 

The  following  list  is  a representative  sample  of  conditions 
which  should  be  included  or  checked  in  acceptance  tests. 
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The  language  and  computer  system  chosen  are  paramount 
to  specification  of  specific  accuracy  tests.  The 
vendor  should  prepare  these  tests  using  at  least  the 
following: 

e existing  compiler  or  hand-calculated  benchmark 
results 

e misspelled  names 
e duplicate  names 
e mode  definitions 
e uninitialised  variables 
e absent  terminators 


e bad  nests  of  all  types 

e improper  variable  modes  (floating  point  loop 
control) 
e recursion 


e improper  data  conversions 
e go's  and  SWITCH'S  on  bad  values 
e constant  redefinition:  CALL  SUB ( 5 ) 


SUB (X) 


X-X+l 


e values  of  FOR  loop  variables  outside  the  loop 
e magnitude  of  loop  variables  (use  large  values, 
negative  values,  etc.) 
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bad  patches 

erroneous  packing  specifications 
improper  semantics 

multiple,  undefined  operator  seguencies:  X*Y++1 
user  un-optimized  code 

compiler  "private"  symbols  and  characters 
floating  point  under flow/overf low 
array  overflow/underflow 
undefined  variables 
misplaced  parameters  (TABLES) 
incorrect  data  types:  FLOAT  ( FLOAT ( 

assembly  language  subprograms 


f • 


Similarly,  both  compilers  would  be  required  to  solve  the 
same  compilation  problems  - parsing,  evaluation,  opti- 
mization, and  code  generation.  If  such  a comparison 
compiler  is  available  - same  language,  host  and  target, 
the  new  compiler  may  be  compared  exactly  on  a test  by 
test  basis. 

Each  compiler  may  excel  or  falter  in  a particular  test 
case  situation.  Therefore,  a compiler  based  comparison 
will,  at  best,  determine  the  "efficiency"  of  the  new 
compiler  only  in  terms  of  the  type  of  test.  Compiler  A 
may  be  efficient  for  small  subprograms  while  Compiler  B 
may  do  better  in  large  program  situations. 

It  appears  that  the  only  reliable  benchmark  for  resource 
utilization  comparisons  is  an  assembly  language  imple- 
mentation of  the  same  application  program. 

The  area  most  likely  to  be  deficient  in  benchmark 
comparisons  is  instruction  set  utilization.  For  example, 
the  statement  ALPH-ALPH  + 1 often  produces 

LOAD  ALPH 
ADD  #ONE 
STORE  ALPH 
IONE  DATA  1 


1 
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This  utilizes  four  memory  locations  and  three  instruction 
"cycles”.  If  the  target  computer  contained  an  increment 
or  memory-add  instruction,  the  code  could  be  reduced  to: 


s 

i 

J 
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INCREMENT 


ALPH 


or 

LOAD 

1 

MADD 

ALPH 

At  this  point,  it  should  be  stressed  that  computer  design 
can  have  a great  deal  of  influence  in  compiler  speeds  and 
core  storage  requirements.  Certain  aspects  of  computer 
architecture  are  especially  important  to  language  processor 
design  and  performance.  In  particular: 
e Direct  Addressing  Capability 

The  computer  should  have  the  ability  to  readily 
address  and  access  information  and  data  consistent 
with  the  system  core  sizing  requirement.  For 
example,  if  the  system  core  requirements  were 
4096  words,  12  bits  of  a computer  word  would  be 
necessary  to  effect  direct  addressing  access; 
if  32,767  words  were  required,  then  15  bits 
would  be  necessary,  etc. 

• Multiple  Purpose  Register  Facility 

The  computer  should  have  a set  of  multiple  registers 
which  can  be  utilized  and  manipulated  in  a variety 


\ 

j 


\ 


\ 
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of  different  fashions.  Several  functional  eharac 
teristic  of  these  registers  are  that  they  should 
function  as: 

a.  Accumulators 

b.  Index  registers 

c.  Masking  registers 

d.  Control  registers 

e Partial  Word  Accessing  and  Utilization  Facility 
The  computer  should  have  the  ability  to  fetch, 
store,  test,  position  and  manipulate  variable 
length  contiguous  portions  of  a computer  word. 
Associated  with  this  capability  must  be  the 
ability  to  treat  the  data  as  signed  or  unsigned 
variable  length  information  when  involved  with 
the  particular  operations, 
e Conditional  Testing  and  Branching  Capability 
The  computer  should  have  the  full  capability  of 
supporting  comparative  relational  conditions 
such  as  equal,  not  equal,  less  than,  less  than 
or  equal,  greater  than,  and  greater  than  or 
equal.  This  capability  must  ideally  provide 
for  register-register,  register-memory  and 
memory-memory  comparative  facility. 


( 

1 

l 

j 

i 
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• Arithmetic  Computational  Capability 

Tha  computer  should  have  the  capability  to 
support  the  full  computational  capabilities 
of  addition,  subtraction,  division,  multipli- 
cation and  negation.  This  facility  should 
provide  for  full  and  partial  word  operations, 
e Shift  Operation  Capabilities 

The  computer  must  have  the  capability  to  support 
both  algebraic  and  logical  shifts  in  two  directions 
on  individual  multiple  purpose  registers  and 
between  multiple  purpose  registers, 
e Logical  Operation  Capabilities 

The  computer  should  have  the  capability  to 
support  the  logical  operations:  AND,  OR,  NOT, 

exclusive  OR,  EQUIVALENCE,  etc. 
e Special  Instruction  Capabilities 

The  computer  should  have  a group  of  special 
purpose  instructions  designed  to  accommodate 
frequently  occurring  programming  situations 
in  the  particular  application  system.  These 
include  the  following  types  of  commands: 

a.  Execute 

b.  Store  zero 

c.  Transfer  on  register  or  memory  zero 
or  non-zero. 
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Transfer  on  register  or  memory  negative 
Halt 

No  operation 


Increment/decrement 


If  the  above  features  are  not  avoidable,  efficiency  ratings 
must  be  adjusted  to  reflect  computer  inadequacies. 


Once  a set  of  assembly  language  benchmarks  has  been 
prepared,  the  following  statistics  may  be  gathered: 

e compilation  time  ■ compilation  computer  time/ 
assembly  computer  time 
e programmer  productivity  » source  program 

preparation  cost/assembly  program  preparation  cost 
e object  storage  * compiled  program  size/assembly 
program  size 

e object  time  ■ execution  time-compiled/execution 
time/assembled 

• numeric  accuracy  ■ precision  of  compiled  program 
results/precision  of  assembled  program  results 

e compilation  storage  ■ total  core  storage  for 
compilation/assembly 

• overhead  time  ■ minimum  cpu  time  necessary  for 
void  or  "nothing”  programs-compilation/assembly 
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• overhead  storage  * minimum  size  of  object  programs 
e capacity  ■ maximum  source  program  size-higher  level/ 
assembly  level 

e peripheral  - devices  used  (tape,  disc,  drum)  and 
number  of  accesses 

Many  of  the  statistics  listed  can  best  be  obtained  using 
built-in  performance  measurement  facilities.  A compre- 
hensive system  for  compilation/execution  measurement 
statistics  gathering  should  be  included  in  every  compiler 
procured.  Their  cost  is  minimal  and  their  value  in 
programmer  aid  and  compiler  "tuning"  is  considerable. 

These  statistics  gathering  facilities  can  be  and  should 
be  capable  of  producing  size  figures  by  statement  type 
for; 

e declaratives 
e assignments 
e data  conversions 
e loop  controls 

e structured  controls  (IP, GOTO,  etc.) 
e input/output 

i 

e modularity  constructs  (subroutine  linkages) 

The  figures  of  merit  in  these  instances  include: 

t 

' e compilation  time 

t 
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e compilation  space 
• register  utilization  in  the  object 
e machine  features  used  - indexing,  indirect 
addressing,  pointers,  overlays,  instruction 
set,  hardware  stacks 
e execution  time 
e execution  space 
e I/O  time 
e I/O  wait  states 
e disk/drum/tape  accesses 
e record  sizes 
e data  region  size 
e bit  size  - packing  (full  word?) 
e number  of  compilations/assemblies  to  working 
programs 

The  resource  utilization  sub-matrix  scores  are  computed 
from  the  statistics  gathered  and  compared  to  empirical 
(desired  or  experienced)  values.  The  actual  assignment 
of  scores  depends  upon  the  statistics  available  and  the 
weight  given  to  each  attribute. 
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RESOURCE  UTILI* 

EATION  STATISTICS 

CATEGORY 

INPUT  ATTRIBUTES 

CPU  Usage 

Compilation  time 
Object  time 
Overhead  time 
I/O  wait  time 

Core  Storage 

Compilation  storage 
Object  storage 
Overhead  storage 
Capacity 

Bit  size  - packing 
Data  region  size 

Instruction  Set 

Instruction  frequency  counts 
Special  instruction  usage 
(increment,  memory  add,  etc.) 

Peripheral  Devices 

I/O  times 

I/O  accesses  by  type  (disk, 
drum,  tape,  etc.) 

Record  sizes 

Registers 

Register  usage  frequency  counts 

Indexing 

Pointers 

Stacks 

CATEGORY  (continued) 


INPUT  ATTRIBUTES 


Addressing  Direct 

Indirect 

Pointers 

Indexed 

Stacks 

Sub-words 

Programmer  Productivity  Number  of  compilations/ 

assemblies  per  program. 
Statistics  available  on 
language  usage. 


Statistics  available  on 
statement  speed  and  bottlenecks. 
Time  to  prepare  programs. 


2.3  User  Interface 


The  acceptability  of  the  compiler  - user  interface  is  not 
as  quantitative  in  nature  as  accuracy  or  resource  utili- 
zation. However,  there  are  several  important  aspects  of 
the  user  interface  which  can  be  identified.  These  include: 

e Partial  compilation  facilities 
e optimization  levels 
e guided  optimization 
e grammar/syntax  checking 
e object  suppression 
e diagnostic  override 

e Assembly  level  facilities 
e assembly  level  listing 
e user  access  to  symbols/tables 
e easy  subroutine  linkages 


Diagnostics 

e explicit  messages  rather  than  numerical  codes 
e error  pinpointing  - to  source  line  symbol,  operator, 
punctuation,  etc. 

e previous  error  recovery  - eliminate  domino-effect 
errors 

e error  messages  within  the  listing,  not  at  the  end 
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• error  levels  - warning,  bad,  disastrous,  etc. 

• error  recovery  - assume  obvious  or  non- fatal 
conditions  and  continue  compilation 

• spelling  - check  for  "close"  spellings  and  proceed 
with  compilation 


A representative  weighting  scheme  is: 


Category 

KSEuBBl 

Acceptable 

Score 

Diagnostics 

35 

29 

Partial  Compilation 

10 

8 

Assembly  Level 
Facilities 

5 

3 

TOTAL 

50 

40 

USER  INTERFACE 


>> 


j 
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2.4  Documentation 

A compiler  may  be  functionally  correct  and  translate 
code  properly  without  being  completely  documented. 

However,  future  maintenance,  extensibility,  re-targeting 
and  user  interfaces  will  suffer  accordingly.  In  addition, 
a poorly  documented  compiler  is  highly  likely  to  be 
an  unreliable  one. 

There  are  three  classes  of  documentation  of  concern  to 
the  procuring  agency:  compiler  implementation,  user's 

guide,  and  operator's  guide. 

In  the  implementation  documentation , several  items  will 
seem  unimportant  upon  initial  receipt  of  the  compiler. 
Nonetheless,  they  will  become  more  apparently  valuable 
as  time  progresses. 

Implementation  Documentation 

e Compiler  limitations  and  idiosyncracies 
e Compiler  source  listings 

e Plow  charts,  prosaic  descriptions  of  every  compiler 
module  and  variable 
e System  interfaces 

e Re-targeting  guidelines  with  a sample  actual  re- target 
effort  • 
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• Extensibility  guidelines  with  a sample  extension 

• Compiler  organization , allocation,  tables  and  packed 
variables 

e Functional  breakdown  (parser,  expressions  evaluator, 
optimizer,  etc.) 
e Each  "pass"  functions 

• Debug  aids  and  measurement  tools 
e Re-generation  procedures 

e Causes  (internal)  of  error  messages 

• Input/output,  records,  blocking,  etc. 

• Language  of  implementation 

e Algorithm  description  - polishing,  parsing,  etc. 

9 Database  definition 

e Parameter  parsing  and  subroutine  linkage 

• Variable  addressing  scheme 

e Lexical  scanning,  text  decoding,  searching 
e Special  modes  such  as  loop-save,  conditional 

• Syntax  analysis 

e Compiler  generated  symbols  and  naming  conventions 
e Access  to  symbols  - symbol  table  structure 

• Proposed  enhancements  and  costs 


j 

This  documentation  must  be  supplemented  by  a comprehensive 

guide  to  expected  modification  difficulties  and  accurate  ] 
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in-line  comments  in  the  compiler  code.  These  comments 
should  be  checked  for  accuracy  against  other  documen- 
tation and  test  results. 

The  second  category,  user  guidelines,  should  be  equally 
exhaustive  and  complete.  However,  unlike  poor  imple- 
mentation documents,  errors  or  omissions  in  user  guides 
will  become  rapidly  and  glaringly  apparent. 

User  Guidelines 

e Diagnostics  - description,  cause,  correction  procedures 
e Language  description  - a comprehensive  user  oriented 
description  of  the  language  implemented  with  numerous 
examples,  cross-referencing  and  job  setup  procedures. 
This  document  should  contain  two  approaches:  beginner's 
tutorial  and  experienced  users'  reference, 
e Capacities,  limits,  minimum  requirements 
e Compiler  idiosyncracies 
e Transferable  programming  guidelines 

e Dialectic  or  subset  differences,  items  not  in  adherence 
to  a standard 
e Visual  training  aids 
e User  flow  charter 
e Assembly /other  language  interfaces 
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The  operator's  guide  is  also  the  type  of  documentation 
that  will  be  immediately  verifiable.  The  procuring 
agency  should  insist  on  a "no-vendor"  installation  by 
agency  personnel.  Most  difficulties  and  omissions  in 
the  operator's  guide  will  be  rapidly  apparent. 


>erator's  Guide 


e Devices  necessary  to  system  residence  (disk  packs, 
system  tapes,  tec.) 

e Peripherals  used  during  execution  - mounting  procedures, 
labeling  conventions,  etc. 

e System  (compiler)  installation  procedures  - step  by 
step 

e Re-generation  procedures 

e Disk  file  maintenance  - scratching  and  compressing 
schedules  and  limits 
e Core  requirements 

e Multi-task  versus  stand-alone  operation 
e Operator  messages  and  responses 
e Compiler  options  (operations  oriented) 
e Hardware/console  switches 


DOCUMENTATION 


Further  explanation  of  the  items  listed  in  this  section 
may  be  found  in  Section  1.9,  Documentation  Specification 
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2.5  System  Interfaces 


User  access  to  computer  files,  linking  of  object  modules 
and  conditional  compiler  use  and  outputs  are  just  a few 
of  the  system  interfaces  each  user  will  experience.  The 
following  items  should  be  provided  by  the  vendor  and 
adequately  described.  Procuring  agency  acceptance  of 
these  items  should  not  be  assumed. 

e Job  control  requirements 
e Operating  system  usage 

e Text  editor  and  similar  utility  interfaces 
e Object  language  interfaces  with  other  system  routines 
and  languages 

e Device  independence /dependence 
e System  subroutines 
e Resource  requirements 
e Compiler  debug  facilities/requirements 
e Load  time  system  overhead-core , devices,  etc. 

• Batch,  remote,  interactive  and  on-time  requirements 

• Execution  time  and  I/O  wait  states  expected  as  a 
function  of  system  load 

• Minimal  configuration 

• Re-entrancy 

• Multi-processing 


For  additional  descriptions  please  refer  to  Section  1.7, 
System  Interface. 
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Actual 

Score 


Category 


Potential 

Score 


Acceptable 

Score 


Job  control 


20 


15 


Resource  Requirements 


System  Routines 


Devices  - I/O 


10 


btillty  Interfaces 


10 


TOTAL 


50 


40 


SYSTEM  INTERFACE 
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2.6  Options 

Section  1.3  discusses  compiler  options  which  may  be 
specified  in  the  procurement  of  a compiler  system. 

Option  requirements  and  needs  are  divergent  among 
installations,  personnel,  and  applications  and  are 
usually  dictated  by  available  resources. 

Of  all  the  optional  features  listed  in  Section  1.3, 
the  most  variable  and  expensive  will  be  optimization. 

The  following  chart  represents  a general  concensus  of 
the  relative  importance  of  the  most  popular  optimization 
techniques  and  can  serve  as  criteria  evaluating  compiler 
optimization  acceptance. 
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COMPILER  OPTIMIZATION  HIERAPCHY 
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Category 

Potential 

Score 

3BSSIS1 

Osar  Debug  Facilities 

12 

10 

Optimization  of  Code 

13 

n 

Measurement  Tools 

17 

15 

Test  Aids 

10 

9 

Documentation  Aids 

S 

4 

Cross/Reference/ 

Dictionary 

3 

2 

Text/Source  Processing 

5 

4 

Partial  Compilation 

2 

2 

Compilation  Directives 

3 

3 

TOTAL 

70 

60 
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2.7  Extensibility 


A compiler  is  extensible  if  it  can  be  easily  modified 
to  include  new  features.  Perhaps  the  best  way  to  test 
for  the  acceptability  of  this  feature  is  to  insist  upon 
a demonstration.  In  other  words,  after  the  compiler 
has  been  implemented  and  delivered  for  acceptance  testing, 
a new  feature,  statement  or  primitive  should  be  added 
to  the  language.  A detailed  written  description  of  all 
steps  taken  to  implement  the  new  feature  should  be  kept. 
This  would  include: 


\ 


* 


• source  updates 

• source  additions  (new  code) 

• re-compilations 

• re- linking 
e self-test 

• errors,  cause  and  corrections 

• man-hours 

• estimated  relative  difficulty 

This  workbook  and  other  deliverable  documentation  should 
give  an  indication  of  the  degree  (score)  to  which  the 
following  extensibility  attributes  have  been  used: 

• documentation 

• modularity  - number  of  programs  changed  and 
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percentage  of  code  changed  in  each  module 
e open-end  deaign  - array  atructurea,  tables, 

intermediate  languages  that  required  re-definition 
e structured  programming  - degree  of  difficulty 
in  locating  appropriate  code  and  success  in 
changing  it 

e compiler  restrictions  - syntax,  usage  of  the 
new  features 

e parameterization  - array  entries,  pointers, 
tables,  parsing  algorithms 

See  Section  1.4,  Extensibility,  for  additional  descriptions. 


Potential 

Score 


Acceptable 

Score 


Actual 

Score 


Category 


Modularity 


8 


Documentation 


Open-ended 


Parameterization 


Structured  Programming 


Compiler  Restriction 
TOTAL 


30 


25 


EXTENSIBILITY 


< 


i 

3 


2-42 


2.8  Transferability 


I 

r 

* 

\ 


1 


> 


t 

j 


Transferability  of  a compiler  can  refer  to  changing  the 
host  or  compiler  resident  computer  or  to  changing  the 
target  or  object  machine.  Perhaps  the  most  likely  and 
therefore  critical  of  the  two  is  re-targeting.  Most 
installations  which  procure  a rather  expensive  compiler 
expect  to  utilize  the  host  machine  for  an  indefinite 
period  of  time.  Mew  applications  and  target  computers 
can  be  required  at  relatively  short  notice,  however. 

The  design  aspects  which  most  directly  effect  transfer- 
ability  of  host  or  target  are  the  same  as  those  listed 
for  extensibility: 

e modularity 

e documentation  and  source  comments 
e parameterization 
e structured  programming 
• open-ended  design 

In  particular,  all  host  and  target  machine  dependent 
attributes  must  have  been  parameterized  and/or  isolated 
to  specifically  identified  modules.  The  documentation 
must  clearly  reflect  all  machine  dependent  constants, 
algorithms  and  programs. 
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The  suggested  test  for  extensibility  is  also  the  best 
way  to  .judge  transferability  - change  the  conditions. 

It  is  considerably  more  expensive  to  re-host  or  re-target 
in  most  instances,  however.  For  this  reason,  the  exten- 
sibility  test  can  be  used  as  an  approximation  of  re-hosting 
difficulties.  If  that  test  showed  high  reliability  of 
comments,  modularity  and  parameterization,  then  the 
re-hosting  task  has  probably  been  minimized.  Of  course, 
re-hosting  difficulties  are  also  a function  of  imple- 
mentation language  - technique.  Self-compiled  or  inter- 
pretative compilers  will  be  most  easily  transferred. 
Assembly  level  coded  compilers  are  virtually  non-trans- 
ferable.  Since  re-targeting  of  the  compiler  is  highly 
probable,  transferability  of  object  is  of  most  immediate 
importance.  Modularity  is  again  the  keyword. 


In  modern  compiler  technology,  it  is  possible  and 
relatively  easy  to  isolate  all  target  machine  dependent 
code  generation  into  one  set  of  independent  modules. 

Optimization  modules,  if  present,  should  be  mathematical 
processes  divorced  from  machine  parameters. 


The  code  generator  portion  of  the  compiler  should  be 
approximately  30%  of  the  total  depending  on  language  and 
target. 
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Again , the  best  way  to  judge  re-targetability  is  to 
procure  another  target  and  insist  on  use  of  agency  or 
different  vendor  personnel  in  the  effort.  If  this  is 
possible , then  the  previously  assigned  scores  for  modularity, 
documentation  and  parameterization  can  be  used  again. 


Acceptable 

Score 


Ron 


Documentation 

20 

Parameterization 

10 

Implementation  Language 

30 

TOTAL 

100 

TRANSFERABILITY  INDICATORS 

Additional  discussion  of  transferability  may  be  found 
in  Part  1. 
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2.9  Schedule  and  Installation 

Assigning  a score  for  schedule  and  installation  performance 
is  a highly  subjective  task.  The  schedule  had  been  deter- 
mined in  the  specification  and  contract  negotiation  phases. 

If  ftfe  is  assumed  that  the  schedule  was  a realistic  one, 
then  failure  to  meet  delivery  dates  and  milestones  will 
probably  result  in  payment  delays.  In  most  cases,  delay 
of  payment  is  usually  sufficient  penalty  to  the  vendor. 

A score  is  somewhat  valuable,  however,  in  helping  to 
determine  efficiency  and  reliability  of  the  compiler. 

Proper  milestones  can  help  to  insure  checkout  and 
acceptance  of  each  phase  of  the  compiler  and  thus 
improve  the  chances  that  the  final  product  will  be 
reliable. 

Schedule  milestones  for  a typical  compiler  project  were  j 

discussed  in  Section  1.10.  For  acceptance  scoring  purposes,  1 


the  following  major  categories  can  be  used. 


Category 

Potential 

Score 

Acceptable 

Score 

Actual 

Score 

Milestones  On-Time 

5 

4 

Documents  Complete  at 
Each  Milestone 

15 

13 

Milestone  coding 
Complete 

10 

9 

Errors  at  Each 
Milestone 

10 

9 

Maintenance 

35 

30 

TOTAL 

35 

__£5 : 

SCHEDULE  AND  INSTALLATION 


J 
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Errors  at  each  milestone  refers  to  the  number  and  severity 
of  errors  encountered  - usual,  fewer  than  usual,  abnor- 
mally large  number,  etc. 

Maintenance  arrangement  refers  to  the  ease  and  rapidity 
in  which  error  reports  are  handled.  Does  the  proper 
person (s)  respond  or  is  the  task  shuffled  from  senior 
to  junior  personnel?  Is  the  time  of  response  acceptable, 
quicker  than  expected,  poor?  Does  there  seem  to  be  a 
lot  of  head-shaking  and  throwing-up-of-hands  or  are 
errors  handled  quietly  and  professionally? 

Milestone  codincr  and  documentation  should  be  complete. 

Was  the  code/document  submitted  just  to  meet  the  dead- 
line and  incomplete  or  inaccurate?  Does  each  milestone 
delivery  "stand  alone"  and  reflect  modular  design 
techniques? 

Training  will  probably  be  given  the  hiqhest  weighting 
in  this  category.  Some  items  to  consider  in  scoring 
the  training  function  include: 

e Adequacy  of  personnel  used  - were  they  the  implementors 
and  users,  or  professional  teachers? 
e Range  of  subject  material  - did  it  include  the  full 
range  from  design  concepts  to  maintenance  and 
enhancements? 


i 
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• Depth  of  subject  material  - was  each  program  module, 
source  language  type,  and  system  generation  procedure 
covered  completely? 

e Time  frame  - is  training  on-going,  repeatable,  hurried, 
etc. 

e Agency  personnel  - are  the  trainees  confident  in  their 
use,  maintenance,  and  modification  ability?  Do  they 
"understand”  the  compiler  or  are  they  just  going 
through  the  motions,  etc.? 

e Options  - were  all  options  explained  and  demonstrated? 

e Error  detection  and  reporting  - were  procedures 
developed  and  explained  for  determining  when  bugs 
exist  and  for  reporting  them  to  the  vendor? 

e Hardware  and  operations  - have  the  proper  personnel 
been  instructed  on  use,  initial  program  load,  error 
recovery,  and  similar  operational  problems? 
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2.10  User  Profile  Adherence 

In  Section  1.8,  several  aspects  of  the  User  Profile  or 
cross-section  of  user  requirements  were  listed.  At  this 
point  in  the  acceptance  testing  of  the  compiler,  the 
procuring  agency  must  determine  if  the  delivered  product 
truly  adheres  to  the  desired  goals  of  the  end-users. 


Several  subtle  changes  may  have  been  introduced  which 
could  have  the  effect  of  eliminating  classes  of  users' 
problems.  For  example,  were  fixed-point  variables 
changed  to  floating  point  for  "efficiency"  by  the 


vendor?  Are  fewer  users  able  to  compile  simultaneously 
while  maximum  source  program  size  has  increased/decreased? 
The  suggested  weighting  scheme  is  based  on  a broad  range 
of  users  and  should  be  changed  according  to  the  parti- 


The  Compiler  Acceptance  Evaluation  Matrix  is  a 
summarization  of  the  sub-matrices  listed  in  Part  2. 

Please  note  that  the  specification  matrices  in  Part  1 
were  not  included  in  the  Acceptance  Evaluation  Matrix. 
Although  it  might  seem  desireable  to  place  specifi- 
cation and  acceptance  items  in  a side-by-side  or 
hierarchial  fashion,  this  is  really  not  meaningful. 

Part  1 discussed  specif ication  decisions,  documents, 
costs  and  similar  items  to  be  prepared  or  studied  by 
the  procuring  agency.  Thus,  a rating  or  performance 
score  cannot  be  assigned  to  these  activities  and  no 
scores  were  assigned  to  specification  items  in 
Part  1 . 

It  is  reasonable,  however,  to  use  the  discussions  in 
Part  1 as  a basis  for  preparing  potential  minimum 
acceptable,  and  actual  criteria  evaluation  scores 
for  the  items  listed  in  Part  2.  If  the  procuring 
agency  stressed  a particular  item  in  its  specification, 
then  all  acceptance  criteria  effected  by  that  item 
would  be  weighted  heavily. 


For  example,  if  precise  language  definition  was  stressed 
in  the  specification,  then  the  accuracy  and  reliability 
of  syntax/semantics  analyzers  (acceptance  criteria) 
would  be  heavily  weighted. 

The  sample  Compiler  Acceptance  Evaluation  Matrix  provided 
is  based  on  a hypothetical  "average"  compiler.  The 
values  assigned,  therefore,  represent  composites  of 
values  derived  from  the  analysis  of  several  languages 
and  their  compilers. 

The  procuring  agency  should  nrepare  a new  set  of 
potential  scores  as  a function  of  language,  project, 
user  group  and  other  constraints  discussed  in  Part  2. 

For  example,  a file  management  system  written  in 
COBOL  would  probably  not  depend  heavily  on  numeric 
accuracy  (past  3 decimal  places)  or  even  resource 
utilization;  but,  it  is  likely  that  system  interface 
would  be  extremely  important. 

In  the  Compiler  Acceptance  Evaluation  Matrix,  the 
following  titles  are  used: 

POTENTIAL  SCORE:  The  weight  or  importance  of 

the  criteria  in  relation  to 
a total  score  of  1000. 
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MINIMUM  ACCEPTABLE 


The  minimum  POTENTIAL  SCORE 


ACTUAL  SCORE: 


PASP/PAIL : 


* 


s 

r 
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which  would  constitute  an 
acceptable  performance. 

The  value  or  percentage  of 
POTENTIAL  SCOPE  which  was 
actually  observed  in  evalu- 
ating or  testing  the  compiler 
criteria. 

A check  indicates  that  the 
actual  score  was  less  than 
acceptable:  a failure.  In 
this  case,  re-work  and  re- 
evaluation  would  be  necessary 
before  total  acceptability 
can  be  attained. 
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EVALUATION  SAMPLE  MATRIX 
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EVALUATION  SAMPLE  MATRIX 


Notes  from  COMPILER  ACCEPTANCE  EVALUATION  SAMPLE  MATRIX 


I 

Note  1 
Note  2 
Note  3 

.1 

Note  4 
Note  5 

i 

i 

Note  6 

» Note  7 

Note  8 
Note  9 


t 


Documentation  incomplete  or  erroneous.  Must  be 
redone.  Note:  Actual  total  exceeds  minimum  yet 

compiler  is  not  satisfadtory  due  to  documentation. 

Compiled  Program  would  not  fit  in  core.  Basic 
benchmark  not  satisfactory.  Code  optimization 
and  more  efficient  code  generator  necessary. 

: Satisfactory. 

Errors  in  documentation. 

Satisfactory. 

Very  Good. 

Errors  in  documentation. 

Incomplete,  erroneous  documentation. 

Would  not  compile  basic  benchmark  adequately. 
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METRIC  SYSTEM 


BASE  UNITS: 

Quantity 


Unit 


length 

mass 

time 

electric  current 
thermodynamic  temperature 
amount  of  substance 
luminous  intensity 

SUPPLEMENTARY  UNITS: 


metre 

kilogram 

second 

ampere 

kelvin 

mole 

candela 


SI  PREFIXES: 


Multiplication  Factors 


1 000  000  000  000  » 1011 
1 000  000  000  - 10* 
i oooooo  - in* 

1 000  - 10J 
100  » 10* 
10  - 10' 
0.1  - 10-' 
0.01  « 10-* 
0 001  » 10-' 
0 000  001  - 10-* 
0.000  000  001  - 10-* 
0.000  000  000  001  - 10“'* 
0 000  000  000  000  001  - 10-'* 
n.ooo  ooo  ooo  ooo  ooo  ooi  - io- •• 


SI  Symbol 


Formula 


m 

kg 

s 

A 

K 

mol 

cd 


•tto 


plane  angle 

rr.dian 

nd 

solid  angle 

steradian 

sr 

Z 

DERIVED  UNITS: 

Acceleration 

metre  per  second  squared 

m/s 

activity  (of  a radioactive  source) 

disintegration  per  second 

(disintegration  Vs 

angular  acceleration 

radian  per  second  squared 

rad/s 

angular  velocity 

radian  per  second 

rad/s 

area 

square  metre 

m 

density 

kilogram  per  cubic  metre 

kg/m 

electric  capacitance 

farad 

F 

A-s/V 

electrical  conductance 

siemens 

s 

A/V 

electric  Held  strength 

volt  per  metre 

V/m 

electric  inductance 

henry 

H 

V-s/A 

electric  potential  difference 

volt 

V 

W/A 

electric  resistance 

ohm 

V/A 

electromotive  force 

volt 

V 

W/A 

energy 

joule 

1 

N-m 

entropy 

joule  per  kelvin 

| IK 

force 

newton 

N 

kg-m/s 

frequency 

hertz 

Hz 

(cycleVs 

illuminance 

lux 

lx 

lm/m 

luminance 

candela  per  square  metre 

cd/m 

luminous  flux 

lumen 

Im 

cd-sr 

magnetic  field  strength 

ampere  per  metre 

A/m 

magnetic  flux 

weber 

Wb 

V-s 

magnetic  flux  density 

tesla 

T 

Wb/m 

magnetomotive  force 

ampere 

A 

power 

watt 

W 

J/s 

pressure 

pascal 

Pa 

N/m 

quantity  of  electricity 

coulomb 

C 

As 

quantity  of  heat 

joule 

1 

N-m 

radiant  intensity 

watt  per  steradian 

W/sr 

specific  heat 

joule  per  kilogram-kelvin 

J/kg-K 

stress 

pascal 

Pa 

N/m 

thermal  conductivity 

watt  per  metre-keivin 

W/m-K 

velocity 

metre  per  second 

m/s 

viscosity,  dynamic 

pascal-second 

Pa-s 

viscosity,  kinematic 

square  metre  per  second 

m/s 

voltage 

volt 

V 

W/A 

volume 

cubic  metre 

m 

wavenumber 

reciprocal  metre 

(weve)/m 

work 

joule 

i 

N-m 

Prefix 

SI  Syi 

tera 

T 

Ki«i 

V, 

mega 

M 

kilo 

'a 

hecto* 

h 

doka* 

da 

decl* 

d 

centi* 

c 

mllll 

m 

micro 

M 

nano 

pIco 

fomto 

n 

r 

* To  be  avoided  where  possible 
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